Transmisión de Datos Mediante soundBLASTER

PROYECTO FIN DE CARRERA Ingeniera de Telecomunicacin
Transmisin de datos mediante SoundBLASTER
Autor: Juan Francisco Izquierdo Len Director: Jos Ramn Cerquides Bueno Escuela Superior de Ingenieros Universidad de Sevilla Marzo de 2002
1 2 3 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.2 3.2.1 3.2.2 3.2.3 3.2.3.1 3.2.3.2 3.2.3.2.1 3.2.3.3 3.2.4 3.2.4.1 3.2.5 3.2.6
Introduccin.................................................................................1 Estructura del proyecto...............................................................2 Desarrollo de la memoria............................................................4 Anlisis y caracterizacin del canal de comunicaciones..............4 Esquema orientativo de una tarjeta de sonido............................. ..5 Ajuste de amplitudes................................................................... ..8 Respuesta impulsiva del canal.......................................................8 Anlisis de ruido del sistema.......................................................14 Seleccin de la tcnica de modulacin y otros parmetros de la transmisin...................................................................................21 Banda de transmisin...................................................................21 Codificacin de lnea...................................................................23 El problema del sincronismo.......................................................27 El problema del sincronismo. Introduccin.................................28 El problema del sincronismo. Desarrollo.....................................29 Clculo del desajuste de frecuencias de muestreo. Ejemplo prctico.........................................................................................30 El problema del sincronismo. Solucin.......................................33 Modulacin empleada..................................................................35 Correspondencia entre bits y smbolos. Amplitudes reales de transmisin...................................................................................48 Estructuracin de los datos. Formacin de tramas.......................51 Diseo del ecualizador o igualador de canal................................57
3.2.6.1 3.2.7 3.3 3.3.1 3.3.1.1 3.3.1.2 3.3.1.2.1 3.3.1.2.1.1 3.3.1.2.2 3.3.1.2.3 3.3.2 3.3.2.1 3.3.2.2 3.3.2.2.1 3.3.2.2.2 3.3.2.2.3 3.3.2.2.4 3.4 3.4.1 3.4.2 4 4.1 4.1.1 4.1.2 4.2 4.2.1 4.2.2 5 5.1
Insercin de seales piloto entre tramas......................................65 Interleaving..................................................................................68 Programacin en Matlab del modulador y demodulador...........70 Cadena transmisora......................................................................71 Programa principal.......................................................................71 TransmiteFichero.........................................................................72 Formacin de tramas....................................................................77 Computacin del CRC en Matlab................................................79 Modulador....................................................................................83 Transmisor...................................................................................88 Cadena receptora..........................................................................91 Programa principal.......................................................................91 RecibeFichero..............................................................................92 Extraccin de tramas....................................................................98 Ecualizacin...............................................................................101 Demodulacin............................................................................103 Formacin del fichero................................................................111 Programacin en C/C++ del modulador y demodulador.........113 Cadena transmisora....................................................................114 Cadena receptora........................................................................137 Manual de uso. Vista del proyecto en funcionamiento.........156 Vista en Matlab..........................................................................156 Transmisor.................................................................................156 Receptor.....................................................................................157 Vista en C...................................................................................158 Transmisor.................................................................................158 Receptor.....................................................................................159 Conclusiones.............................................................................161 Propuestas de mejora y lneas futuras de trabajo.....................163
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster
Juan Francisco Izquierdo Len
1 Introduccin
La tarjeta de sonido SoundBlaster de Creative Labs y compatibles aportan grandes posibilidades a la hora entender de forma prctica muchos aspectos tericos propios de ingeniera de telecomunicaciones desarrollados a lo largo de toda la carrera. El objetivo principal de este proyecto es permitir la comunicacin entre dos ordenadores, en la forma de transmisin de ficheros (datos), utilizando las lneas LINE IN y LINE OUT de sus respectivas tarjetas de sonido. Durante el desarrollo de la memoria, se estudiar el porqu de la modulacin utilizada; adems, para optimizar el diseo, se calcularn todas las posibles velocidades de transmisin que el sistema es capaz de soportar, de forma que la probabilidad de error de bit sea mnima (esto redundar, como es lgico, en alguna deficiencia en otro lugar del sistema, como explicar ms adelante). Veremos, entre otras muchas cosas, algunos conceptos claves de recuperacin de sincronismo, formacin de tramas IEEE (con alguna variacin que luego indicar), montado de smbolos en un sistema M-ario, codificacin de lnea, ecualizacin o igualacin de canal y la forma de llevar a cabo la modulacin y demodulacin en un sistema de comunicaciones basado en un cable de audio, con todas las limitaciones que eso conlleva (escassimo ancho de banda, atenuacin relativa, etc).
2 Estructura del proyecto

El proyecto podemos dividirlo en 5 apartados fundamentales:
1. Anlisis y caracterizacin del canal de comunicaciones

En este apartado se har hincapi en la obtencin de la funcin de transferencia del sistema completo:
CABLE DE AUDIO
Del estudio de la respuesta impulsiva y de la respuesta en frecuencia de dicho sistema, podremos determinar el ancho de banda del canal. Adems, estudiaremos el nivel de ruido presente y su influencia en el sistema.
2. Seleccin de la tcnica de modulacin y otros parmetros de la transmisin

En este punto, lo ms destacado ser la eleccin de la tcnica de modulacin a utilizar. Este resultado ser derivado inmediatamente del apartado anterior (estudio del canal digital de comunicaciones) y la decisin se tomar de acuerdo con varios factores fundamentales: La velocidad de transmisin Minimizacin de errores ptima utilizacin del espectro disponible
El siguiente paso es el tratamiento de los datos a transmitir. Formaremos tramas Ethernet, tomando como base la recomendacin IEEE 802.3. Estudiaremos si es necesario o no introducir entrelazado de bit (y con qu profundidad, si fuera necesario), as como la
cantidad de cdigos cclicos para el tratamiento de errores, con el objetivo de conseguir las prestaciones calculadas anteriormente.
3. Programacin en Matlab del modulador y demodulador

Aqu es donde se implementarn todas las rutinas que harn que el proyecto pueda llevarse a cabo de la mejor manera posible. Para las pruebas se utilizarn archivos de audio (.WAV) que, en el extremo transmisor, sern reproducidos y, en el extremo receptor, sern registrados en la tarjeta de sonido correspondiente. Finalmente, la transmisin se implementar obviando dichos ficheros de audio, pasando directamente los datos a transmitir hacia la tarjeta de sonido y registrando los datos recibidos en variables del sistema.
4. Programacin en C/C++ del modulador y demodulador

Para concluir la fase prctica, se trasladar el cdigo Matlab a un par de aplicaciones externas en C/C++ que se ejecutarn en el transmisor y en el receptor respectivamente.
5. Conclusiones y posibles ampliaciones

En este ltimo apartado, resumir las conclusiones fundamentales de este proyecto punto por punto, de forma que queden claras todos los apartados bsicos del tema en cuestin, enfatizando los aspectos ms importantes que se han tratado para el estudio, diseo y realizacin de un sistema de transmisin de datos que permita conectar dos ordenadores, uniendo las lneas LINE IN y LINE OUT a travs de un cable de audio.
sta ha sido la estructura que he llevado a cabo en la prctica y ser, tambin, la estructura que seguir en el desarrollo de esta memoria.
3 Desarrollo de la memoria
3.1 ANLISIS Y CARACTERIZACIN DEL CANAL DE COMUNICACIONES
Lo primero que debemos hacer para conseguir la respuesta del canal de comunicaciones es conectar el cable de audio entre LINE IN de una tarjeta y LINE OUT de la otra, o bien, conectar el cable entre las lneas LINE IN y LINE OUT de una misma tarjeta; esta segunda opcin es slo posible en el caso de que dicha tarjeta de sonido se FULL-DUPLEX, es decir, que tenga la facilidad de reproducir y grabar datos simultneamente. En el caso de que el reloj utilizado por una tarjeta full-duplex para reproducir y grabar sea el mismo, no podremos observar un problema fundamental que aparece cuando se hace la conexin entre PCs distintos (relojes distintos, claro): el problema del sincronismo, derivado del desajuste en las frecuencias de los relojes de transmisin y recepcin. Ya lo veremos detenidamente, pues ahora nos interesa nicamente estudiar la forma de onda que adquiere la transmisin de un impulso en recepcin (respuesta impulsiva o impulsional del sistema) y su transformada de Fourier (respuesta en frecuencia del sistema). El siguiente paso es establecer los ajustes adecuados en el mezclador (o mezcladores, si la tarjeta no es full-duplex, lo cual nos obligara a hacer las pruebas con dos PCs). Para ello, es necesario conocer, ms o menos bien, el funcionamiento interno de una tarjeta de sonido. Intentar aclararlo con el esquema de la pgina siguiente:
3.1.1 ESQUEMA ORIENTATIVO DE UNA TARJETA DE SONIDO
LINE IN
A/D
1 2 3
MIC IN
A/D
Grabacin
Volume Control
SPK OUT
Adaptador de impedancias
Volume Control
LINE OUT FUERA DE LA TARJETA DENTRO DE LA TARJETA CD Audio
6 7
WAVE
Reproduccin 5
8 MIDI
Desde el mezclador de la tarjeta de sonido, lo que hacemos internamente es controlar los amplificadores del sistema ( ) . Estos dispositivos amplifican lo que tienen a la entrada, pudiendo aumentar o disminuir el nivel de seal a la salida de los mismos. Las distintas fuentes que controlan estos amplificadores pueden ser de dos tipos: 1) INTERNAS (Wave, Midi y CD Audio, principalmente) 2) EXTERNAS (LINE IN y MIC IN)
El dispositivo de reproduccin de CD realmente es externo, pero la conexin se realiza dentro del ordenador, por lo que se considera que es una fuente interna. Dentro del mezclador encontramos dos tipos de controles: reproduccin y grabacin. Con el de reproduccin, controlamos qu enviamos a la salida de la tarjeta (la salida de la tarjeta es LINE OUT pero, en muchos modelos de tarjetas de sonido, suele ser la misma que SPK OUT), y con el de grabacin, controlamos lo que queremos que la tarjeta de sonido registre cuando la ponemos a grabar fuentes externas). Nuestro objetivo es generar una seal dentro del ordenador, enviarla por LINE OUT y recogerla por LINE IN. Por lo tanto, la posicin de los interruptores debe ser sta: En reproduccin: Interruptor 7, WAVE, cerrado. As permitimos el envo de un sonido procedente de un fichero almacenado en el PC. Volume Control (Master Gain) debe estar obligatoriamente cerrado pues, si no, no saldra nada de la tarjeta. Todos los dems interruptores deben estar abiertos.
En grabacin: Interruptor 1, LINE IN, cerrado. Todos los dems interruptores deben estar abiertos.
Por tanto, el objetivo est conseguido: reproducir un fichero interno y grabar slo LINE IN, obviando las dems fuentes. En definitiva, la posicin de los interruptores debe ser:
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster 1 cerrado, 2 abierto, 3 abierto, 4 abierto 5 abierto, 6 abierto, 7 cerrado, 8 abierto, 9 cerrado
MUY IMPORTANTE: Es totalmente necesario anular todo tipo de efectos 3D (tridimensionales) que pueda poseer la tarjeta. Si no se hace as, el sistema no funciona, debido a que el ecualizador en el receptor no es capaz de engancharse a la respuesta impulsiva 3D del canal digital. Para quedarlo ms claro an, voy a ilustrarlo con un ejemplo de la ventana del mezclador de MS Windows Millennium: A) CONTROL DE REPRODUCCIN
B) CONTROL DE GRABACIN
Una vez realizados todos los ajustes en los mezcladores para reproducir y grabar correctamente, el siguiente paso es elegir los formatos de reproduccin que vamos a utilizar durante todo el proyecto. Para optimizar los resultados usaremos el conocido formato de sonido: PCM 44100 Hz; 16 bit; mono (calidad de CD con un solo canal) De esta forma podremos asegurar que la tarjeta de sonido funciona al mximo de sus posibilidades (las restricciones vendrn despus). El hecho de usar el formato mono y no estreo es, obviamente, porque vamos a transmitir por un solo canal. As pues, el cable puede ser estreo (dos hilos) o mono (1 hilo) ya que, realmente, vamos a usar slo un hilo (canal). Sin embargo, la aplicacin final permitir elegir el valor de la frecuencia de muestreo y la resolucin de la tarjeta de sonido (8 16 bits) para, entre otras cosas, hacerla compatible con cards antiguas.
3.1.2 AJUSTE DE AMPLITUDES

Para que todo funcione correctamente es necesario hacer un ajuste de amplitudes en el transmisor y en el receptor. Se trata de que no saturemos lo que transmitimos ni tampoco lo atenuemos en exceso. Por lo tanto, deberemos generar, por ejemplo, una senoide de 10 KHz (frecuencia intermedia que no cae en los extremos de la banda) de amplitud mxima (+1: 32767 con formato de 16 bits). La transmitimos con la configuracin actual del mezclador de la tarjeta. Si aparece cortada o, por el contrario, muy atenuada, deberemos ajustar la ganancia de las lneas LINE de entrada y salida, de forma que obtengamos una respuesta a esa senoide con la mxima amplitud y sin que llegue a cortarse por exceso del nivel de seal de entrada procedente de la otra tarjeta. Una vez hecho esto, ya estamos en disposicin de transmitir lo que deseemos por el cable de audio.
3.1.3 RESPUESTA IMPULSIVA DEL CANAL

Para hacer el estudio del canal de comunicaciones (cable de audio), lo mejor es transmitir un impulso. En recepcin veremos la respuesta a dicho impulso (respuesta impulsiva o impulsional del sistema). Esquemticamente:
x[n]=[n] CABLE DE AUDIO
y[n]=h[n]
En este punto ya podemos entrar en Matlab para crear una delta de Dirac [n]: es una sola muestra con el mximo valor posible, es decir, con el valor +1, ya que nos moveremos en el rango desde 1 a +1, con las propiedades de sonido anteriores. Podemos interpretar esto en el rango de 16 bits, de forma que: VALOR NORMALIZADO +1: 216-1 = 32768-1=32767 VALOR NORMALIZADO -1: -2-16 = -32768 La secuencia para crear una delta y almacenarla en un fichero .WAV para transmitirla podra ser sta:
%delta de dirac d=1; wavwrite(d,44100,16,'c:\jf\pfc\delta.wav');
Es decir, hemos creado un fichero .WAV (delta.wav) que contiene el impulso a transmitir, con las propiedades PCM indicadas anteriormente. La transmisin se realiza utilizando la Grabadora de Sonidos de Windows o programa similar que nos permita reproducir y grabar sonidos. Siempre comenzaremos a grabar en recepcin con suficiente antelacin para evitar problemas de transitorio indeseados. As pues, veamos la respuesta al impulso del sistema. Para ello reproducimos delta.wav en un extremo y lo registramos en el otro. x[n]=[n]:
Im puls o 1 0. 9 0. 8 0. 7 0. 6 0. 5 0. 4 0. 3 0. 2 0. 1 0
0. 2
0. 4
0. 6
0. 8
1. 2
1. 4
1. 6
1. 8
La respuesta a este impulso es la respuesta impulsiva del sistema (h[n]) y la podemos ver en las siguientes figuras:
a) Muestra a muestra
Respuesta al impulso 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 -0.1 -0.2 0
10
15
20
25
30
35
40
45
50
b) De forma continua
500
1000 1500 2000 2500 3000 3500 4000 4500 5000
10
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster Podemos apreciar inmediatamente dos cosas: El gran parecido con una funcin Sampling.
Una atenuacin del nivel de seal, pues no alcanza la amplitud +1.
El siguiente paso es ver la respuesta en el dominio de la frecuencia (respuesta frecuencial) tanto en mdulo (amplitud) como en fase:
Ya tenemos una estimacin de la respuesta del canal. A primera vista notamos que el canal tiene caracterstica LPF (Low Pass Filter) pero un estudio detallado de las frecuencias en torno a 0 (DC) nos muestra que realmente se trata de un sistema BPF (Band Pass Filter) dado que aparece un corte a 3dB que se produce aproximadamente a la frecuencia de 20Hz. Podemos intuir esto en la figura anterior, pues la respuesta del sistema tiende caer en torno al origen.
11
Por consiguiente, el sistema bloquea el paso de seales de frecuencia 0 (seales de continua o de DC). Veamos un ejemplo muy ilustrativo. Transmito una seal continua de mxima amplitud (ones(1,1000) en Matlab, por ejemplo) por el canal y recibo esto:
Como era de esperar, el canal no deja pasar el nivel de continua y esto se ve reflejado en una cada exponencial de constante de tiempo , relacionada con la inversa del ancho de banda del sistema (B), es decir 1/B. Es muy parecido a la respuesta de un sistema de primer orden. En definitiva, tenemos un canal que deja pasar componentes de frecuencia en el rango aproximado de 20Hz-20KHz, que, curiosamente, coincide con el rango terico de audicin del odo humano, si bien es cierto que en la prctica no omos ms all de los 15KHz aproximadamente. Por otra parte, vemos que la respuesta frecuencial en mdulo no es completamente plana, sino que existen ciertos valles en donde la atenuacin es mayor que en el resto del espectro. Esto ya lo podramos haber deducido viendo la respuesta temporal del sistema: recordemos que se pareca mucho a una funcin Sampling, pero no lo era exactamente
12
debido a que la cada por los extremos no es totalmente suave y paulatina. Vemoslo de nuevo:
500
1000 1500 2000 2500 3000 3500 4000 4500 5000
Estas dos prominencias que impiden esa cada suave propia de las funciones Sampling son las responsables de que la respuesta frecuencial en mdulo no sea totalmente plana. Recordemos la relacin funcin Sampling - funcin rectngulo que exista en la dualidad tiempo frecuencia. Como la Sampling no es perfecta en nuestro sistema, la respuesta frecuencial no es totalmente plana (es relativamente sencillo comprobarlo en Matlab). El hecho de que nuestra respuesta no sea totalmente plana nos forzar a introducir un elemento clave en el receptor. Se trata de un igualador de canal o ecualizador y su objetivo ser modificar los datos de forma que parezca que la respuesta del sistema fuera la ideal. Es decir: TX CANAL h[n] RX ECUALIZADOR e[n]
13
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster y el objetivo ser hacer posible que h[n]*e[n]=[n]
Antes de llevar a cabo el diseo del ecualizador es necesario realizar un anlisis de ruido del sistema para determinar qu modelo de igualador es mejor. Es decir, por ejemplo, si el ruido presente en el sistema fuera importante, lo ms adecuado, con toda probabilidad, sera realizar un filtrado de Wiener; si, por el contrario, no fuera as, habra que estudiar la forma de realizar un diseo de ecualizador que no tuviera en cuenta el ruido presente como, por ejemplo, un filtro inverso o un filtro de cero forzado (ZF).
3.1.4 ANLISIS DE RUIDO DEL SISTEMA

En este apartado, como he indicado antes, haremos un anlisis del ruido presente en el sistema. Estudiaremos su importancia para, posteriormente, disear un igualador de canal ptimo. Hay varias formas de llevar a cabo este anlisis, pero voy a centrarme en la que, a priori, parece ms intuitiva de todas: la transmisin en vaco. Se trata de hacer una transmisin de una cadena larga de ceros, es decir, como si no transmitiramos nada, de forma que, en recepcin, tendremos el ruido presente en el sistema y, posiblemente, interferencias procedentes de la frecuencia de la red elctrica y sus primeros armnicos: 50Hz / 100Hz / 150Hz.
Hc(f)
Snn(f) Interferencias
Por tanto, procedemos a realizar la transmisin en vaco (todo ceros). Utilizamos para ello un programa de edicin de sonido como el Cool Edit 2000, aunque se puede ver tambin en Matlab.
14
Las grficas ms representativas del ruido recibido cuando se realiza la transmisin en vaco son stas:
A la vista de esta figura, observamos que el ruido presente es realmente escaso. Es ms, se hace necesario un zoom muy grande (1x10000) para poder apreciar que existe realmente este ruido:
15
El zoom realizado es definitivo. Como podemos observar, hemos pasado de una escala vertical en el rango [-1,1] a otra en un rango muy pequeo del orden de 10-4. Por lo tanto, concluyo afirmando que, aunque existe ruido, ste es tan pequeo que no es necesario tenerlo en cuenta para realizar el ecualizador. No obstante, voy a determinar cul es su densidad espectral. La densidad espectral de ruido Snn(f) es un concepto importante para determinar varias cosas. Nos dar una idea de la distribucin en frecuencia de las componentes del ruido y, adems, nos avisar si se cuela en el sistema alguna interferencia, como cit antes: Una rutina para calcularla en Matlab podra ser, por ejemplo, sta:
%Estimacin de Snn(f) a la salida ruido=wavread('ruido'); %Lectura del ruido registrado [Snno,F]=PSD(ruido,2046,44100); %Power Spectral Density plot(F,10*log10(Snno));grid; xlabel('Frecuencia'); ylabel('Densidad espectral de ruido de sistema (dB)');
Es decir, se realiza la lectura del ruido registrado por el sistema a travs de la funcin de Matlab wavread, pues lo almacenamos previamente en un fichero de audio .WAV. Con la funcin PSD (de Matlab tambin) calculamos la densidad espectral de potencia y, finalmente, la dibujamos. Si la ejecutamos, obtenemos una grfica como la que aparece en la siguiente pgina:
16

-40
Densidad espectral de ruido de sistema (dB)
-50
-60
-70
-80
-90
-100
0.5
1 Frecuencia
1.5
2.5 x 10
4
Ntese de nuevo la escasa importancia del ruido pues la grfica muestra dB de potencia. Cabe destacar que el ruido de alta frecuencia es ms importante, aunque tampoco mucho ms. S es interesante, por el contrario, estudiar qu ocurre en baja frecuencia, con objeto de determinar la importancia de las posibles interferencias. Debemos, por tanto, realizar de nuevo un zoom en esta zona. Sin embargo, dada la estaticidad de programas como Matlab, para apreciar correctamente este hecho, es mejor utilizar un programa que nos permita trabajar en tiempo real. El programa SpectraLab es una opcin interesante para ello, aunque esto mismo puede verse en Cool Edit a partir de la FFT del ruido:
17
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster Vista lineal:
Vista logartmica:
En este caso, NO aparecen armnicos en las frecuencias 50/100/150 Hz.
18
En el hipottico caso en que existieran interferencias de los armnicos de la red, la solucin que yo propongo es el Mtodo de Estimacin de Mxima Versosimilitud, mediante el cual se puede estimar la amplitud, la frecuencia y el desfase de las mismas. Es decir, el mtodo nos permitira estimar la interferencia existente para, posteriormente eliminarla:
x[n]
y[n]=x[n]- Asen(2 f + )
La aparicin de este tipo de interferencias procedentes de la red elctrica es un problema que no hay que olvidar aunque, sin embargo, no hay que concederle demasiada importancia debido principalmente a la escasa influencia que una sola frecuencia concreta con una amplitud relativamente pequea puede tener en todo un bloque de transmisin. En definitiva, la capacidad de este concepto para abortar una transmisin es bastante pobre. En este momento resulta interesante corroborar, haciendo uso del anlisis de ruido, que la funcin de transferencia del sistema es realmente la que se obtuvo anteriormente. Recordemos que antes conseguimos un resultado formado por la representacin frecuencial del mdulo y la fase de la respuesta del sistema. Lo hice transmitiendo un impulso por el canal, viendo, en recepcin, la respuesta impulsiva. Pues bien, otra forma de obtener el mdulo de la respuesta frecuencia es estimar |Hc(f)|2, de la siguiente manera:
Snno(f)= |Hc(f)|2 Snni(f)
Para ello, creamos un ruido blanco con un editor de sonido (por ejemplo, Cool Edit), calculamos su densidad espectral de potencia Snni(f), lo transmitimos por el canal, lo registramos en recepcin y calculamos, tambin, su densidad espectral de potencia Snno(f). Ya lo tenemos todo; tan slo es necesario despejar |Hc(f)|2 . Vemos la rutina que permite hacer todo esto en Matlab:
%Clculo de abs(H)^2 a travs del ruido r=wavread('ruidoblanco'); %Lectura del ruido blanco creado %artificialmente a transmitir por el %canal rx=wavread('ruidoblancorx'); %Lectura del ruido blanco recibido
19

Sni,F]=PSD(r,2046,44100); Sno,F]=PSD(rx,2046,44100); H2=Sno./Sni; plot(F,10*log10(H2));grid; %Snno %Snni
%Representacin del mdulo de la %respuesta frecuencial del sistema al %cuadrado
Ejecutndola, obtenemos la siguiente grfica, que representa el mdulo de Hc(f) al cuadrado:
Se confirma, efectivamente, la forma de la respuesta frecuencial del sistema. Hay que resaltar que esto es una estimacin y por esta razn no obtenemos una respuesta limpia sino que aparece algo as como un ruido superpuesto que nos invita a pensar que se trata de fluctuaciones en torno a la respuesta deseada (tiene varianza). En definitiva, la media de esta figura es la respuesta real del sistema obtenida anteriormente a partir de la transformada de Fourier de la respuesta al impulso.
20
Por tanto, veamos las conclusiones ms importantes obtenidas hasta este momento en lo que se refiere al anlisis y caracterizacin del canal de comunicaciones: Es un canal paso-banda (BP). A simple vista, viendo la respuesta completa en frecuencia, parece que se trata de un canal paso-bajo, pero no es as. Esto se obtiene, realmente, haciendo pruebas como, por ejemplo, transmitir una seal continua, apreciando, en recepcin, que el canal bloquea el paso de DC; tambin se poda apreciar realizando un zoom a bajas frecuencias en la respuesta frecuencial (caracterstica de amplitud o mdulo) del sistema.. Su ancho de banda es de aproximadamente 20KHz, es decir, se extiende desde los 20Hz hasta algo menos de los 20KHz. No tiene una respuesta en frecuencia totalmente plana, lo cual nos obligar a introducir, en la cadena de recepcin, un bloque de ecualizacin o igualacin de canal, con objeto de contrarrestar la atenuacin producida por el cable en ciertas bandas de frecuencia. El ruido presente en el sistema no es tan importante como para que haya que realizar un filtrado de Wiener, de forma que la ecualizacin ser suficiente y eficiente si se lleva a cabo con un filtrado que no tenga en cuenta el ruido como, por ejemplo, filtrado inverso o de cero forzado (ZF). En el siguiente bloque implementaremos su diseo. En el hipottico caso de que existieran interferencias producidas por los armnicos de la red (50Hz, 100Hz, 150Hz, etc), el mejor mtodo para eliminarlas del espectro es el Mtodo de Estimacin de Mxima verosimilitud. Otra posible manera de eliminarlas podra ser la introduccin de filtros de bloqueo o filtros peine. Recordemos que este problema puede aparecer aunque su importancia no sea excesiva.
21
3.2 SELECCIN DE LA TCNICA DE MODULACIN Y OTROS PARMETROS DE LA TRANSMISIN

En este segundo bloque de la memoria del proyecto derivaremos, a partir del estudio del canal de comunicaciones realizado en el primer bloque, las caractersticas ms importantes de la transmisin. Justificaremos el porqu de la tcnica de modulacin utilizada, detallando las prestaciones ofrecidas, y, adems, optimizaremos algunos parmetros importantes de la codificacin, tales como la profundidad de entrelazado de bit o smbolo (interleaving), si fuera realmente necesario, y la capacidad de deteccin de errores proporcionada por los cdigos cclicos en aras de obtener unas prestaciones prefijadas con anterioridad. Los puntos a tratar sern, por este orden, los siguientes:
Determinaremos en qu banda de frecuencia realizaremos la transmisin.
Optimizaremos el diseo con un cdigo de lnea adecuado a las caractersticas del canal de comunicaciones.
Trataremos un problema clave: el problema del sincronismo. Como consecuencia de este desajuste, descartaremos algunos tipos de modulacin.
Elegiremos la tcnica de modulacin que emplearemos en el sistema de transmisin.
Estudiaremos la mejor forma de estructurar los datos en tramas. Tratamiento de errores.
Disearemos de forma terica el igualador de canal o ecualizador, de acuerdo con la escasa importancia del ruido presente en el sistema.
Y, finalmente, antes de pasar al bloque de programacin en Matlab, discutiremos el uso o descarte de la tcnica de interleaving.
Comenzamos.
3.2.1 Banda de transmisin

Utilizamos una transimisin digital en banda base o una transmisin digital paso de banda?
22
Lo ms inmediato para responder a esta pregunta sera fijarse en las caractersticas en frecuencia del canal, de modo que nos acoplramos, de la mejor forma posible, al ancho de banda disponible para realizar la transmisin:
Disponemos de un canal con un ancho de banda de aproximadamente 20KHz, lo cual es realmente muy pequeo si lo comparamos con otro tipo de sistemas LAN con tarjetas Ethernet, que pueden conseguir hasta 100 Mbps de tasa binaria.
Aunque el sistema propiamente dicho es un sistema apoyado en un canal paso de banda, realmente podramos considerarlo a efectos prcticos como paso bajo. Esto es as dado que la frecuencia de corte de 3 dB, en la parte de bajas frecuencias de la respuesta en frecuencia, aparece en torno a los 20 Hz. Es decir se trata de un canal que principalmente deja pasar bajas frecuencias (hasta 20KHz) y, adems, absorbe el nivel de continua, puesto que se trata de un sistema BP.
Del punto anterior podemos deducir inmediatamente que, al tratarse de un canal que deja pasar frecuencias en el rango aproximado de 20Hz20KHz, no resulta nada ptimo realizar un diseo basado en una transmisin digital paso de banda. Si se hiciera de esa forma, habra que realizar un desplazamiento en frecuencia realmente pequeo y absurdo, con la consiguiente complejidad que conlleva introducir osciladores en el sistema que trasladen las seales a otra banda.
Es por todo esto por lo que es ms conveniente llevar a cabo una transmisin digital en banda base. Ahora bien, habr que tener en cuenta que el canal bloquea el paso del nivel de continua.
3.2.2 Codificacin de lnea

Si la transmisin digital adoptada es en banda base y el canal absorbe el nivel de DC, cmo se puede solucionar esto?
Evidentemente, hay que pensar en primer lugar que el canal me impide que transmita seales con un cierto nivel de continua. Adems, he descartado transmitir en otra banda de frecuencia que no sea la banda de bajas frecuencias (si hubiera elegido la transmisin digital paso de banda, el problema se solucionara de inmediato dado que el canal es paso de banda tambin). Por lo tanto, deberemos hacer algo para evitar transmitir seales con nivel de DC, an sabiendo que nuestro espectro estar centrado a priori en =0 rad/seg (transmisin digital en banda base). Sin duda, la solucin a este problema reside en el tipo de codificacin de lnea. 23
En definitiva, con la codificacin de lnea debemos superar el hecho de que el canal sea paso de banda y queramos transmitir en banda base, sin hacer ningn tipo de modificacin en el espectro. Utilizaremos PCM como formato para la codificacin de muestras. Los pulsos compuestos por la agrupacin de muestras cumplirn todos los requisitos exigidos a la codificacin de lnea utilizada. PCM no es un cdigo de lnea. El formato utilizado PCM (Pulse-Code Modulation) literalmente podra traducirse del ingls como Modulacin por Pulsos Codificados y, si entendemos modulacin como la modificacin de las caractersticas de una seal, rpidamente nos damos cuenta de que este significado no es muy correcto y, por tanto, la traduccin no es correcta del todo. PCM no es un sistema de modulacin, sino un sistema de codificacin, por lo que una traduccin ms propia sera Codificacin de Pulsos Modulados. Las exigencias que deben cumplir los cdigos de lnea son las siguientes:
Capacidad de autosincronizacin: poder definir cul es el mejor reloj (Tb).
Robustez frente a los errores: distincin de forma robusta de los distintos niveles de amplitud.
Debe ser un cdigo transparente, es decir, que no dependa de la secuencia que transmitimos.
Debe tener un espectro adaptado al canal que utilicemos para la transmisin.
Recordemos los principales cdigos de lnea existentes: Unipolar NRZ Unipolar RZ Polar NRZ Polar RZ Bipolar NRZ Bipolar RZ Manchester
RZ: retorno a cero NRZ: sin retorno a cero
24
El cdigo ms interesante para nosotros es el cdigo de lnea basado en el tipo de codificacin Manchester. Es en este cdigo en el que nos basaremos. En el mtodo de codificacin Manchester (tambin conocido como Bifase), el smbolo 1 es representado por un pulso positivo seguido de un pulso negativo, ambos con la misma amplitud (A) y duracin (medio ciclo). Por el contrario, el smbolo 0 se representa por un pulso negativo seguido de un pulso positivo, ambos con la misma amplitud (A) y duracin (medio ciclo). Es decir, las polaridades de estos pulsos son inversas.
Vemoslo grficamente:
1 A T 0 -A T/2 t A
0 -A
T/2
La codificacin Manchester suprime la componente de DC y tiene relativamente insignificantes componentes de baja frecuencia, considerando la estadstica de la seal. Esta propiedad es esencial en muchas aplicaciones. Veamos, tambin, grficamente una estimacin de la densidad espectral de potencia (PSD) del cdigo Manchester o bifase en banda base:
PSD
f 1/2T 2/2T 3/2T
25
Se puede observar que no existe componente de continua y, por tanto, nuestro problema (transmisin digital en banda base sobre canal paso banda) parece resuelto.
Ejemplo: Supongamos que es necesario transmitir datos (agrupados en una trama) que poseen un cierto nivel de continua negativo (por debajo de cero). Dado que el cable de audio es paso banda, si no utilizamos codificacin Manchester, el nivel de DC es absorbido por el canal. Vemoslo:
La figura nos permite comprobar, efectivamente, que la trama se ha deformado completamente, degradndose como consecuencia de la prdida de su nivel de continua. Evidentemente, esto no es recuperable mediante la ecualizacin, pues este nivel ya lo ha absorbido el canal. La conclusin es que la utilizacin del cdigo de lnea Manchester o Bifase es necesaria absolutamente, dado que, si no se hace as, el canal atenuar exponencialmente las tramas transmitidas en banda base, de la misma forma que observamos en la grfica anterior.
26
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster banda:
Hemos realizado, en cierta forma, una caracterizacin de un canal limitado en
hc(t)
RUIDO n(t)
Tericamente, este canal podra intentar modelarse como un canal AWGN no ideal (su respuesta en frecuencia no es ideal): est limitado en banda. Por este hecho, no podemos transmitir todo lo rpido que queramos. Adems, el hecho de transmitir en un canal limitado en banda implica la existencia de una interferencia de los smbolos futuros en los actuales: existe interferencia entre smbolos (ISI) pues el canal deforma los smbolos transmitidos. En nuestro caso, la ISI ser mnima debido a que transmitiremos con una frecuencia de muestreo de 44100 Hz. Esta frecuencia cumplir el criterio de Nyquist para la transmisin sin distorsin en banda base.
3.2.3 El problema del sincronismo

Hasta ahora hemos dicho que la transmisin digital ser en banda base por cuestiones referentes a las caractersticas de baja frecuencia del canal, a pesar de que absorbe las componentes de DC de las seales que transmitimos. Esto se solucionaba con la codificacin de lnea Manchester o Bifase. Hacer el diseo basndose en una transmisin digital paso de banda no es ptimo debido a las dificultades que introduce: La traslacin del espectro requiere el uso de osciladores. Adems, como veremos a continuacin, los problemas de sincronismo debidos a desfases en las frecuencias de muestreo de transmisin y recepcin sern otro factor muy importante, aadido a la utilizacin de osciladores, para descartar la tcnica de transmisin paso de banda.
27
Por lo tanto, ya estamos en disposicin de desechar algunas tcnicas de modulacin clsicas. Es decir, modulaciones utilizadas frecuentemente en canales paso de banda, consistentes en la modificacin de caractersticas de la seal tales como la fase, la amplitud, la frecuencia, etc, no formarn parte de nuestras opciones a la hora de elegir la tcnica de modulacin. A saber:
Modulacin PSK (phase-shift keying) Modulacin FSK (frecuency-shift keying) Modulacin ASK (amplitude-shift keying) Modulacin de fase continua. MSK Modulacin QAM Modulacin ortogonal no coherente Modulacin DPSK Etc
que no son ms que derivaciones de las modulaciones PM, FM y AM, en donde interviene una seal portadora, generalmente de carcter sinusoidal. Para justificar estos descartes, es necesario hacer aqu un pequeo parntesis para explicar el problema del sincronismo. Este problema es tan importante que, una vez comprendido, no ser necesario aclarar de nuevo por qu la transmisin digital ser en banda base. La introduccin de una portadora en entornos no sincronizados sera definitiva para desechar la transmisin digital paso de banda.
3.2.3.1 El problema del sincronismo. Introduccin

Cuando todos pensamos en el diseo y realizacin de un sistema de transmisin, lo ms lgico es pensar que los relojes del transmisor y del receptor van muy parejos, con una precisin muy elevada. Esto es lo normal, es decir, lo tpico es que las frecuencias de muestreo del transmisor y del receptor sean iguales. En nuestro sistema de transmisin, el transmisor y el receptor no son ms que una tarjeta de sonido. Las tarjetas de sonido actuales poseen la capacidad de poder generar sonidos utilizando una amplia gama de frecuencias de muestreo. Es decir, pueden variar la frecuencia de muestreo de los relojes que utilizan los convertidores D/A y A/D del 28
transmisor y del receptor, respectivamente. De esta forma, si se generan sonidos con un determinado formato de reproduccin PCM, compuesto por una frecuencia de muestreo fs, un determinado nmero N de bits por muestra y una caracterstica mono o estreo, cuando hay que registrarlos en otra tarjeta de sonido, debemos utilizar el mismo formato de grabacin PCM. Si no se hiciera as, registraramos algo totalmente distinto a lo que reproducimos en la tarjeta de sonido transmisora. Esto mismo podemos verlo de otra forma muy sencilla utilizando una sola tarjeta de sonido. Se trata de generar un sonido con un editor como el CoolEdit y salvarlo con formatos distintos. Cuando escuchemos dichos sonidos captaremos las diferencias.
3.2.3.2 El problema del sincronismo. Desarrollo

Vamos a centrarnos ahora en el problema del sincronismo, detallando todas sus caractersticas y posibles soluciones. El problema de sincronismo se centra en que las frecuencias de muestreo no son exactamente iguales en ambos casos. Es lo que vara en el formato PCM utilizado. Como indiqu al principio de la memoria, voy a usar el formato base se sonido: PCM 44100 Hz; 16 bit; mono (calidad de CD con un solo canal) Con ms detalle:
Formato de sonido PCM: no es, como dije anteriormente, un sistema de modulacin de pulsos codificados sino un sistema de codificacin de pulsos modulados. Por lo tanto, se trata de codificar (muestreo y cuantizacin previo) una seal para convertirla en digital.
Frecuencia de muestreo 44100 Hz. Aunque actualmente existen tarjetas que permiten la utilizacin de frecuencias de muestreo mayores como, por ejemplo, 48000 Hz, pero, dado que la calidad de CD (44100 Hz) es la ms extendida popularmente, har uso de ella. En qu consiste el hecho de que la frecuencia de muestreo sea de 44100 Hz? Consiste en que en la duracin de un segundo, tendremos 44100 muestras, o, de otra forma, en que la separacin entre una muestra y la siguiente ser de 1/44100 segundos.
16 bits por muestra de resolucin: cada muestra la codificaremos con 16 bits, es decir, visto en el rango de 16 bits, una muestra podr ser codificada desde 32768 hasta 32767 que, si lo normalizamos, equivaldra al rango entre 1 y 1.
No obstante, he dejado la puerta abierta a usar menos bits por muestra (8 bits) para hacerlo compatible con tarjetas de sonido ms antiguas, as 29
como a utilizar una frecuencia de muestreo distinta a 44100 Hz, por la misma razn y, adems, para intentar solucionar el problema del sincronismo en casos extremos.
Por ltimo, utilizaremos un solo canal de transmisin; de ah que la caracterstica de sonido sea mono y no estreo, que equivaldra realmente a dos canales.
De todos los conceptos antes descritos, este problema afecta al desajuste existente en las frecuencias de muestreo del transmisor y del receptor. Es decir, los relojes no permitirn el uso de una frecuencia de muestreo exacta de 44100 Hz, sino que:
El reloj de transmisin funcionar a una frecuencia de 44100 T Hz
El reloj de recepcin funcionar a una frecuencia de 44100 R Hz
donde R y T son cantidades relativamente pequeas en relacin a la frecuencia base de 44100 Hz y dependen, en todo caso, de la calidad de las tarjetas de sonido empleadas.
3.2.3.2.1 Clculo del desajuste de frecuencias de muestreo. Ejemplo prctico.

Para determinar el desajuste existente entre dos relojes, desde el punto de vista de su frecuencia de muestreo, podemos partir de una onda sinusoidal de una frecuencia 11025 Hz, submltiplo de 44100 Hz, que es la frecuencia de muestreo que utilizaremos. Esta senoide tiene la peculiaridad de tener sus muestras distribuidas de una forma muy interesante para nuestro propsito. Para ilustrar esto, veamos un ejemplo de lo que ocurre en una tarjeta de sonido SoundBlaster 128PCI en configuracin full-duplex (permite reproduccin y grabacin simultnea y, curiosamente, el reloj interno es distinto para cada caso: apreciaremos falta de sincronismo). Generamos la senoide anterior de 11025 Hz:
%senoide de frecuencia fc FSAM=44100; %frecuencia de muestreo %frecuencia de oscilacin fc=11025; %nmero de periodos a dibujar N=5; A=1; %amplitud t=0:1/FSAM:N/fc; s=A*sin(2*pi*fc*t); stem(t,s)
30
y vemos, por ejemplo, 5 ciclos:
1 0.8 0.6 0.4 0.2 0 -0.2 -0.4 -0.6 -0.8 -1
0.5
1.5
2.5
3.5
4.5 x 10
5
-4
Ya podemos ver la peculiaridad que tiene una onda sinusoidal de frecuencia 11025 Hz, cuando se muestrea a una frecuencia de 44100 Hz: las muestras caen en el mximo (+1), en cero (0) y en el mnimo (-1), de forma que cualquier pequeo desajuste se percibir inmediatamente. El siguiente paso es transmitirla y examinar qu obtenemos en recepcin. Para observar el problema de sincronismo es necesario transmitir una senoide de las mismas caractersticas de antes pero de mucha ms duracin, ya que si la onda es corta en tiempo, no notaremos qu ocurre (el desincronismo es un fenmeno apreciable a lo largo del tiempo, claro). Entonces, partimos de un tono como el anterior, lo transmitimos y obtenemos algo similar a esto:
31
Qu ha ocurrido aqu? Por qu aparece esta sinusoide tan rara con una amplitud, a simple vista, variable y no fija como la que se transmiti? Lo que ha ocurrido es debido a que las frecuencias de muestreo son distintas en transmisin y en recepcin. Es ms, aunque no lo parezca, la amplitud de la envolvente es siempre la misma y constante, siendo el efecto visual provocado por el movimiento de las muestras, pues ya no aparecen arriba, en cero y abajo, sino que, como existe este desajuste frecuencial, aparecen movidas. Voy a tratar de explicar cmo se hara el clculo del citado desajuste de una forma muy aproximada. Se trata de coger el tono de 11025 Hz (insisto en la importancia de este valor submltiplo de 44100 Hz, pues con otro valor al azar no sera posible verlo), y muestrearlo, con Matlab por ejemplo, a distintas frecuencias cercanas a 44100 Hz (mayores y menores) hasta obtener algo similar a la figura anterior. Haciendo varias pruebas con distintas frecuencias, observo que, utilizando FSAM=44100.5 Hz FSAM=44099.5 Hz, el resultado es casi perfecto. Vemoslo:
32
Por lo tanto, podemos concluir que el desajuste existente en este ejemplo es de aproximadamente 0.5 Hz, lo cual significa que cada 2 segundos se pierde o se gana una muestra, segn el extremo desde donde se mire. Esta diferencia de medio Hertzio es relativamente pequea si la comparamos con lo que podemos encontrar en otro tipos de tarjetas compatibles con SoundBlaster. En tarjetas de baja calidad este desajuste puede ser escandaloso (varias decenas de Hertzios); afortunadamente, el odo humano es insensible a esto, pero es interesante saber el porqu de algunos precios tan bajos en el mercado. Es decir, cuando creemos que la calidad de un sonido reproducido en una tarjeta compatible es la calidad de CD (44100 Hz), realmente puede no ser as, degradndose considerablemente. Esto es irrelevante a la hora de escuchar sonidos, pero es ESENCIALMENTE IMPORTANTE cuando queremos que estos relojes formen parte de un sistema de transmisin de datos.
3.2.3.3 El problema del sincronismo. Solucin

Dar una solucin a este importante problema sera muy fcil si los relojes fueran modificables va hardware con algn tipo de potencimetro o algo similar, de forma que los ajustes seran definitivos. Sin embargo, esta posibilidad queda totalmente descartada pues, actualmente, todas las tarjetas tienen un alto grado de integracin, lo cual nos impide cualquier tipo de intervencin externa.
33
Esto nos obliga a estudiar otras opciones. Entre ellas, podemos destacar la posibilidad que tienen muchas tarjetas de funcionar con distintas frecuencias. Por ejemplo, supongamos que tenemos una tarjeta Soundblaster bien ajustada y una tarjeta de mala calidad que no dispone realmente de 44100 Hz como frecuencia base, sino 44062,26. En estos casos tan desfavorables, una buena solucin es aprovechar la capacidad de la tarjeta SoundBlaster para modificar su frecuencia base: puede transmitir o recibir (segn sea transmisora o receptora) a una frecuencia de 44062 Hz, pues su resolucin es de 1 Hz, es decir puede funcionar perfectamente 44099, 44098, 44097, etc, hasta llegar a lo que nos interese. Cuando nos hemos adaptado a la tarjeta de mala calidad, ya tenemos la seguridad de que el desajuste existente no excede 1 Hz, aunque, claro est, habremos perdido prestaciones en cuanto a velocidad ya que la frecuencia de muestreo utilizada ya es menor que los 44100 Hz iniciales. Por lo tanto, la situacin en este momento es la siguiente: el transmisor y el receptor tienen relojes cuyas frecuencias de muestreo son parecidas, aunque no estn totalmente sincronizadas, dado que existe una pequea diferencia de algo menos de 1 Hz. Es con esto con lo que el proyecto va a tener que funcionar y no lo podemos modificar. Sin embargo, an nos queda una opcin. Con un desajuste menor que 1 Hz, podemos observar que durante intervalos de tiempo algo menores que 1 segundo, la sincronizacin no es perfecta, pero si muy buena. A saber, podemos aprovechar este hecho para transmitir nuestros datos en los intervalos de tiempo en donde existe sincronizacin, olvidndonos de las colas de tiempo en las que el desajuste se hace visible e importante. Por lo tanto, ajustaremos el tamao de las tramas que tenemos que transmitir (lo disminuiremos, se sobreentiende) para que el problema del sincronismo nos afecte lo menos posible. Por lo tanto, para concluir el tema de la falta de sincronismo, la conclusin ms importante es que la transmisin ser en banda base. No es difcil imaginar lo que podra ocurrir si se realizara una transmisin paso de banda: el hecho de incluir una portadora para modificar el espectro y desplazarlo unos pocos hertzios ms arriba, con el objeto de adaptar nuestros datos al canal paso de banda, puede llegar a ser un autntico caos debido al desajuste existente en las frecuencias de muestreo; podra valer, en ltima instancia, si la transmisin se apoyara en unas tramas de longitud ultracorta (esto no es ptimo), en las cuales no se apreciara tal efecto. Sin embargo, nuestro propsito es formar tramas de longitud mxima, de forma que optimicemos el diseo del transmisor y del receptor con el menor nmero de bucles posible, y los bucles, claro est, se ejecutarn ms veces cuanto menor sea la longitud de las tramas, haciendo mucho ms lento el sistema (recordemos que, en Matlab, las llamadas a funciones son un factor clave en la velocidad de las aplicaciones). Adems, las tramas largas tienen la ventaja de transmitir ms datos reales procedentes del fichero respecto a datos referentes a inicio de trama, longitud del campo de datos y, sobre todo, CRC. Esto que he dicho acerca de los inconvenientes de utilizar una transmisin paso de banda se puede observar con mucha claridad si se realiza una transmisin digital ASK 34
(Amplitude Shift Keying) con varios niveles de amplitud (M-aria): smbolos de nivel alto en el transmisor se confunden con smbolos de nivel bajo en el receptor, y viceversa, debido al movimiento de muestras provocado por el desajuste en las frecuencias de muestreo. NOTA: Podra ocurrir que este desajuste fuera realmente pequeo y no fuera necesario intervenir para encontrar una solucin; sera el caso de tener 2 tarjetas de sonido de muy buena calidad. No es habitual, pero si ocurre que, efectivamente, no tenemos este problema, el diseo y realizacin del sistema de transmisin de datos se simplificara muchsimo, pues desapareceran muchos inconvenientes; adems, podramos llevar a cabo la transmisin paso de banda (aunque, en este caso, no creo que fuera ptima, de todos modos), aumentar la longitud de las tramas, el nmero de niveles utilizados en la modulacin, etc.
3.2.4 Modulacin empleada

La modulacin en banda base que desarrollar ser la modulacin PAM (PulseAmplitude Modulation). Para la transmisin digital en banda base, el uso de discrete pulseamplitude modulation (PAM) es la tcnica de modulacin ms eficiente en trminos de:
Consumo de potencia
Utilizacin espectral del ancho de banda disponible
ste es el sistema ms simple en el caso de sistemas digitales y, adems, en banda base, es el ms utilizado. Por lo tanto, voy a centrar mi atencin en los sistemas discretos PAM. Para empezar, voy a fijarme en los sistemas binarios y, posteriormente, en los sistemas M-arios con varios niveles de amplitud. He de decir en este punto que el sistema final diseado tanto en Matlab como en C/C++ ser totalmente configurable para que el usuario escoja, entre otras cosas, el nmero de niveles de amplitud que desee, desde M=2 (transmisin binaria, ON/OFF), hasta un mximo indeterminado fijado por las condiciones del canal y el ajuste del transmisor y del receptor. Particularmente, considero que M=16 ya empieza a dar problemas en entornos con falta de sincronismo, pero, no obstante, ser posible su utilizacin.
Entremos en materia. Consideremos un sistema binario en banda base PAM. De forma genrica, podemos observarlo en la figura siguiente:
35
TRANSMISOR
{bk} Modulador de amplitud de pulso (PAM) {ak} Filtro transmisor g(t) s(t)
Canal h(t)
CANAL
Ruido n(t)
RECEPTOR
0 Bloque de decisin 1 y(ti) t=ti y(t) Filtro receptor c(t) x(t)
Umbral
La secuencia binaria de entrada {bk} es una secuencia compuesta por ceros y unos, cada uno de duracin Tb. El modulador de amplitud transforma esta secuencia binaria en una nueva secuencia de pulsos cortos (aproximadamente un impulso unidad), cuya amplitud ak se representa de la siguiente forma:
36
+1 ak = -1
si el smbolo bk es 1 si el smbolo bk es 0
La secuencia de pulsos cortos producida es aplicada a un filtro transmisor de respuesta impulsiva g(t), produciendo la seal transmitida:
s(t) =
a
k
g (t kTb )
Esta seal s(t) es modificada como resultado de la transmisin a travs del canal de respuesta impulsiva h(t). Adems, el canal aade ruido aleatorio a la seal en la entrada del receptor (como dije antes, este ruido es prcticamente despreciable cuando el cable de audio es de mediana calidad). La seal ruidosa x(t) se pasa entonces a travs de un filtro receptor de respuesta impulsiva c(t). La salida resultante es muestreada de forma sincronizada con el transmisor (recordemos que esta sincronizacin era un problema muy importante si la transmisin era paso de banda, con la introduccin de una nueva frecuencia portadora que desplazase el espectro), de forma que los instantes de muestreo son determinados por el reloj de la tarjeta (otra forma sera que estos instantes de muestreo los determinara una seal de sincronismo que extrajera el receptor de los datos, pero, nuevamente, si tenemos problemas de sincronismo, no es viable). Finalmente, la secuencia de datos as obtenida se usa para reconstruir la secuencia original de datos mediante el bloque de decisin. En concreto, la amplitud de cada muestra es comparada con un umbral de decisin . Si este umbral es excedido, la decisin se hace a favor del smbolo 1. Si este umbral no es excedido, la decisin se hace a favor del smbolo 0. Si la amplitud de la muestra es exactamente igual al umbral, la decisin es totalmente aleatoria. La salida del filtro receptor podemos expresarla as:
y(t) = a k p(t kTb ) + n(t )

k
donde es un factor de escala y p(t) representa el efecto de la transmisin desde el transmisor hasta la salida del filtro receptor. Es decir, p(t) se obtiene mediante la convolucin que envuelve a la respuesta impulsiva g(t) del transmisor, la respuesta impulsiva h(t) del canal y la respuesta impulsiva c(t) del filtro receptor:
37
p(t)=g(t)*h(t)*c(t)
Podramos recordar aqu que para llevar a cabo una transmisin en banda base sin distorsin o distorsin mnima, p(t) deba cumplir una serie de condiciones de acuerdo con el criterio de Nyquist. Las condiciones de Nyquist se pueden observar en el dominio del tiempo y en el dominio de la frecuencia. A modo de resumen:
En el dominio del tiempo, p(t) deba ser 1 en el instante de muestreo, y 0 en los dems casos.
En el dominio de la frecuencia, su espectro P(f) deba ser lo ms plano posible, de forma que la interferencia entre smbolos fuera mnima.
Ambas condiciones son equivalentes. Todo esto iba encaminado a escoger un determinado pulso de transmisin que evitara la aparicin de ISI, como, por ejemplo, pulsos en coseno alzado. Sin embargo, en nuestro caso, este problema no es muy grave. Dado que voy a intentar optimizar al mximo la velocidad del sistema, utilizar el menor nmero posible de muestras por smbolo, de manera que ni siquiera habr tiempo material para la formacin de pulsos en coseno alzado. As, me limitar a utilizar pulsos rectangulares (con la conveniente codificacin de lnea Manchester), con el objetivo de que el propio igualador de canal presente en el receptor pueda solucionar este problema. Este problema de interferencia entre smbolos, por otra parte, es de una importancia mnima en nuestra aplicacin dado que la frecuencia utilizada es de 44100 Hz y la mxima frecuencia de seal es algo menor de 20 KHz: fs>2fm y, por lo tanto, el criterio de Nyquist se cumple con bastante holgura (>4 KHz). Debido a que el sistema posee un escassimo ancho de banda, cualquier pequeo aumento de la tasa de transferencia es significativo. Por esta razn, el hecho de utilizar slo dos niveles de amplitud es un handicap. Para optimizar la velocidad del sistema, podemos recurrir a la transmisin digital con varios niveles. La formacin de smbolos con distinta amplitud tiene ventajas e inconvenientes:
Con un smbolo, estaremos transmitiendo varios bits de una sola tirada.
Sin embargo, esto complica el diseo del transmisor y del receptor pues debern procesar ms de dos amplitudes (caso binario).
38
El objetivo debe ser optimizar al mximo la utilizacin del escaso ancho de banda de que disponemos (apenas 20 KHz), de forma que la conclusin es simple: la transmisin en banda base ser M-aria, sin olvidar la posibilidad de transmitir en binario (M=2). En la parte de programacin en Matlab del modulador y demodulador, veremos que esto complica un poco las cosas, pero las ventajas obtenidas son mucho ms importantes. En el sistema binario en banda base PAM, el modulador genera pulsos binarios, es decir, pulsos con uno de dos niveles posibles de amplitud. En el caso M-ario, el modulador de amplitud genera uno de M niveles posibles de amplitud, con M 2. Por ejemplo, para el sistema cuaternario (M=4) y la secuencia binaria de datos 0010110111, la forma de onda sera:
Amplitud 0 +1.5 +0.5 t -0.5 -1.5 0 1 0 1 1 0 1 1 1
La representacin elctrica de cada uno de los cuatro posibles dibits (pares de bits) se muestra en la siguiente tabla:
Dibit 00 01 10 11
Amplitud -1.5 -0.5 +0.5 +1.5
39
Recordemos que en un sistema M-ario, la fuente de informacin emite una secuencia de smbolos a partir de un alfabeto de M smbolos. Cada nivel de amplitud en la salida del modulador de amplitud PAM corresponde a un smbolo distinto, de forma que existen M niveles de amplitud distintos para ser transmitidos. En un sistema M-PAM en donde la duracin de un smbolo es T, la tasa de smbolo es 1/T smbolos por segundo o baudios (es importante distinguir entre bits por segundo y baudios). En general, un baudio es igual a log2M bits por segundo (bps), y la duracin de smbolo T de un sistema M-PAM est relacionada con la duracin de bit Tb del correspondiente sistema binario PAM a travs de:
T = Tb log2M
Por lo tanto, en un ancho de banda dado, si usamos un sistema PAM, podemos transmitir informacin a una tasa que es log2M veces ms rpido que el correspondiente sistema binario PAM. Sin embargo, para conseguir la misma probabilidad de error de bit (BER), un sistema M-PAM requiere ms potencia transmitida. En un sistema M-ario PAM, la secuencia de smbolos emitida por la fuente de informacin es convertida, en el modulador de amplitud de pulsos PAM, a un tren de pulsos PAM de M niveles, que ser la entrada del transmisor. Este tren de pulsos, igual que ocurre en el sistema binario PAM, adquiere forma fsica de onda en el filtro transmisor y, posteriormente es transmitido a travs del canal digital de comunicaciones (nuestro cable de audio), que corrompe nuestra seal con ruido y distorsin. La seal recibida se ecualiza en el receptor y posteriormente se demodula, todo ello en el bloque de recepcin. En este punto hay que hacer un muestreo con una tasa apropiada, sincronizada con el transmisor. Cada muestra es comparada con los distintos valores umbral (ahora hay ms de uno, pues la transmisin es M-aria) y se decide en favor de un smbolo transmitido de los M posibles. En general, interferencia entre smbolos (ISI), ruido y deficiencias en la sincronizacin causan errores que son visibles en el receptor. Por lo tanto, los filtros transmisor y receptor deben disearse para minimizar estos errores. Vamos a particularizar un poco ms para nuestro sistema concreto de transmisin de datos mediante SoundBlaster. Anteriormente hice alusin al posible nmero mximo de niveles de amplitud de nuestro sistema M-ario PAM. Dije que con M=16 el sistema no es muy robusto frente a errores y aparecen numerosos fallos de transmisin, sobre todo en entornos en donde no existe una sincrona medianamente buena. No obstante, si la sincrona es de muy buena calidad, M=16 no slo es mejor sino que es recomendable pues la velocidad del sistema se incrementara notablemente.
40
As pues, M=16 (4 bits por smbolo) se puede usar sin ningn problema siempre que sepamos con seguridad que las frecuencias de muestreo de los relojes del transmisor y del receptor sean muy precisas, es decir, que no haya variaciones, por ejemplo, de ms de 0.5 Hz entre ellas y, adems, sean estables y no flucten. En el siguiente escaln podemos bajar hasta M=8 (recordemos que el nmero M de niveles debe cumplir que M=2x), es decir, un smbolo se construye con 3 bits de una secuencia binaria de entrada en el modulador PAM. Este valor ya es mucho ms razonable y hace mucho ms estable y menos propenso a errores al sistema. El inconveniente ms importante es que la velocidad de transmisin se ha reducido bastante respecto al sistema 16-PAM, pues en el intervalo de tiempo en donde antes podamos enviar 4 bits, ahora tan slo enviamos 3 bits. En cunto disminuye la tasa de bit del sistema? Vemoslo: El nmero de smbolos transmitidos por segundo es lo que se denomina tasa de smbolo del sistema y se define as:
D=
1 TSYM
Rb 1 = kTb log 2 M
donde k=log2M es el nmero de bits que debemos agrupar para constituir un nico smbolo y Rb=1/Tb la tasa de bit. Cada TSYM transmito uno de los M posibles smbolos. En definitiva, si pasamos de M=16 a M=8, la tasa de bit sufre la siguiente variacin:
M=16: Rb16=4D
M=8: Rb8=3D
es decir, considerando que la duracin de un smbolo es la misma en ambos casos, la velocidad de transmisin en un sistema 8-PAM es un 25% menor que en un sistema 16PAM (insisto en que esto es vlido siempre que TSYM sea igual en las dos situaciones). Los sistemas binario y cuaternario, equivalentemente, verifican que:
M=4: Rb4=2D
M=2: Rb2=D
Para empezar a ver nmeros reales de transmisin, es necesario definir el tiempo de smbolo TSYM. Esto es lo mismo que preguntarse cuntas muestras vamos a usar para 41
transmitir un smbolo M-PAM. Recordemos que la frecuencia base de muestreo utilizada en este sistema es de 44100 Hz principalmente aunque, como dije con anterioridad, este parmetro tambin podr ser elegido por el usuario de la manera que considere oportuno, siendo coherente con las frecuencias de muestreo utilizadas por su tarjeta de sonido (actualmente, si la tarjeta es de calidad -Sb128PCI y superiores-, debe soportar hasta 48000 Hz tanto en reproduccin como en grabacin). La duracin de un smbolo tambin est influenciada por el desajuste en las frecuencias de muestreo. La demodulacin puede complicarse mucho entornos no sincronizados. Deberemos tener esto muy presente, con el siguiente criterio:
El nmero de muestras necesarias para la codificacin de un smbolo: o Debe aumentar cuando la desincronizacin es importante, con el consiguiente descenso en la velocidad del sistema. o Puede disminuirse considerablemente cuando el ajuste de frecuencias de muestreo es bueno, con objeto de maximizar la tasa de transferencia.
La codificacin de lnea empleada en el sistema para la formacin de smbolos es la codificacin Manchester (N muestras/smbolo):
A T/2 0 -A T t
Lgicamente el valor de A puede ser uno de los M posibles niveles de amplitud. La separacin entre una muestra y otra, si la frecuencia de muestreo es de 44100 Hz, es de 1/44100 = 22.6757 seg
Esto significa que, si cada smbolo est formado por N muestras (nmero par), entonces:
el periodo de smbolo es TSYM = N 1/44100
la tasa de smbolo es D=1/TSYM=44100/N
42
En la siguiente tabla muestro datos reales para distintos valores de N:
N 2 4 6 8 10 12
TSYM (mseg) 0.04535 0.09070 0.13605 0.18140 0.22675 0.27210
D (smb/seg) 22050 11025 7350 5512.5 4410 3675
Esto, equivalentemente, da lugar a una tasa de bit Rb que depende el nmero M de niveles empleados en la modulacin:
Rb=Dlog2M
En las siguientes tablas podemos apreciar cmo varan las velocidades binarias, segn el valor de M. Estudiar solamente los casos citados antes, es decir, M=2, 4, 8 y 16, para los distintos valores de N (nmero de muestras por smbolo). Empezar por N=2 (mnimo numero de muestras por smbolo: sistema ms rpido pero ms propenso a errores en la transmisin) y terminar por N=12 (nmero elevado de muestras por smbolo: sistema ms lento pero muy robusto frente a errores en la transmisin):
43
N=2 (D=11025smb/seg) M 2 4 8 16 Rb(bps) 22050 44100 66150 88200
N=4 (D=22050smb/seg) M 2 4 8 16 Rb(bps) 11025 22050 33075 44100
44
N=6 (D=7350smb/seg) M 2 4 8 16 Rb(bps) 7350 14700 22050 29400
N=8 (D=5512.5smb/seg) M 2 4 8 16 Rb(bps) 5512.5 11025 16537.5 22050
45
N=10 (D=4410smb/seg) M 2 4 8 16 Rb(bps) 4410 8820 13230 17640
N=12 (D=3675smb/seg) M 2 4 8 16 Rb(bps) 3675 7350 11025 14700
46
Estos datos son bastante importantes ya. En un principio, antes de empezar a hacer pruebas con el proyecto, las cuentas que yo tericamente haca (sistema M-ario), dado que el ancho de banda B es de aproximadamente 20 KHz y la frecuencia de muestreo es de 44100 Hz, eran las siguientes:
B=B0(1+)
REGLA DE CARSON
CASO IDEAL: pulsos de Nyquist, =0 B0=D/2 D=2B 40000 simb/seg
lo cual dara lugar a una tasa de bit: a) 2-PAM: b) 4-PAM: c) 8-PAM: Rb=Dlog2M=40000log22=40 Kbps Rb=Dlog2M=40000log24=80 Kbps Rb=Dlog2M=40000log28=120 Kbps
d) 16-PAM: Rb=Dlog2M=40000log216=160 Kbps
CASO REAL: pulsos coseno alzado, =1 B0=D/2 D=B 20000 simb/seg
lo cual dara lugar a una tasa de bit: a) 2-PAM: b) 4-PAM: c) 8-PAM: Rb=Dlog2M=20000log22=20 Kbps Rb=Dlog2M=20000log24=40 Kbps Rb=Dlog2M=20000log28=60 Kbps
d) 16-PAM: Rb=Dlog2M=20000log216=80 Kbps
Sin embargo, esto se qued en una ilusin cuando comenc a transmitir datos realmente. Por ejemplo, el nmero de muestras que pensaba transmitir por smbolo era una solamente; posteriormente me di cuenta de que el canal absorba el nivel de DC,
47
bloqueando el paso de continua, lo cual me oblig a usar el cdigo de lnea Manchester (mnimo 2 muestras). Por tanto, las caractersticas que debe tener nuestro sistema son:
M-ario PAM con un mximo de 16 niveles.
El nmero de muestras necesarias para formar un smbolo en codificacin de lnea Manchester ser N, nmero par: N=2, 4, 6 , 8, 10, 12...
siendo ambos datos totalmente configurables por el usuario, adems de la frecuencia de reloj utilizada y la resolucin empleada (n de bits/muestra: 8 16).
3.2.4.1 Correspondencia entre bits y smbolos. Amplitudes reales de transmisin

Con objeto de que el sistema ser un poco ms robusto frente a errores, la correspondencia entre bits y smbolos la basar en el cdigo Gray, que tiene la ventaja de reducir la probabilidad de error de bit (BER). Se trata, pues, de una pequea contribucin de cara a mejorar las caractersticas del sistema en cuanto a la minimizacin de errores de transmisin. Es una alternativa ventajosa sobre la correspondencia binaria natural. Sin embargo, utilizar cdigo Gray tiene el inconveniente de aadir una pequea complicacin en el transmisor y en el receptor: es necesario introducir algunas rutinas de conversin de cdigo binario natural a cdigo Gray y viceversa, as como un LOOK-UP TABLE (se trata, sin entrar en mucho detalle an, de modificar una tabla). Para ilustrar los distintos sistema M-PAM propuestos (M=2, 4, 8, 16) voy a dibujar tablas representativas de la correspondencia entre bits y smbolos, anotando los valores reales de amplitud en el rango normalizado 1,...,+1:
SISTEMA 2-PAM (SISTEMA BINARIO)
Palabra de 1 bit 0 (0) 1 (1)
Smbolo 0 1
Amplitud real -1 +1
48
SISTEMA 4-PAM
Palabra de 2 bits 00 (0) 01 (1) 10 (2) 11 (3)
Smbolo 0 1 3 2
Amplitud real -1 -0.3333 0.3333 +1
SISTEMA 8-PAM
Palabra de 3 bits 000 (0) 001 (1) 010 (2) 011 (3) 100 (4) 101 (5) 110 (6) 111 (7)
Smbolo 0 1 3 2 7 6 4 5
Amplitud real -1 -0.7142 -0.4285 -0.1428 +0.1428 +0.4285 +0.7142 +1
49
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster SISTEMA 16-PAM
Palabra de 4 bits 0000 (0) 0001 (1) 0010 (2) 0011 (3) 0100 (4) 0101 (5) 0110 (6) 0111 (7) 1000 (8) 1001 (9) 1010 (10) 1011 (11) 1100 (12) 1101 (13) 1110 (14) 1111 (15)
Smbolo 0 1 3 2 7 6 4 5 15 14 12 13 8 9 11 10
Amplitud real -1 -0.8666 -0.7333 -0.6 -0.4666 -0.3333 -0.2 -0.0666 +0.0666 +0.2 +0.3333 +0.4666 +0.6 +0.7333 +0.8666 +1
50
3.2.5 Estructuracin de los datos. Formacin de tramas.

Los datos que vamos a enviar por el cable de audio deberemos estructurarlos adecuadamente, es decir, es necesaria la formacin de tramas de datos. Hay dos razones principales para ello:
Facilitar la labor del transmisor y del receptor, liberndolos de clculos excesivos.
Evitar los problemas de falta de sincronizacin.
La primera razn se explica rpidamente: supongamos que tenemos un fichero a transmitir con un tamao de 100 KB, por ejemplo. Si quisiramos transmitirlo en una sola trama, nos encontraramos con un agotamiento de la CPU del PC, provocado por la gran cantidad de datos que debera manejar y manipular tanto el transmisor y el receptor, ms an sabiendo que un smbolo no puede transmitirse, por los problemas ya indicados, con una sola muestra, sino que habra que usar varias muestras. En segundo lugar, tenemos el problema del desajuste en los relojes. Es necesario crear tramas de una longitud adecuada, de forma que no se puedan desincronizar transmisor y receptor durante el tiempo en que transcurre en el envo. Esto es fundamental y es tan importante o ms que el problema de falta de memoria disponible y velocidad del microprocesador en un PC. Realmente, mi opinin es que la formacin de tramas, en la mayora de los sistemas de transmisin, se realiza con objeto de hacer frente a la desincronizacin entre transmisor y receptor, cuidando mucho que no se agoten con tramas ultralargas. Entrando ya de lleno en este apartado, una vez entendida la necesidad de la estructuracin de los datos en tramas, lo mejor es partir de la conocida recomendacin IEEE 802.3 o, ms popularmente, Ethernet. Las tramas (tambin conocidas como paquetes de informacin) que enva cada computadora por el cable de audio deben tener un formato especfico y cumplir unas normas establecidas. En una red esto es fundamental: tienen que ser comprendidos por todos los usuarios de la misma (ampliar este proyecto al diseo de una red podra ser una excelente ampliacin para el futuro). Esas normas cobijan aspectos como la longitud de los paquetes, cdigos para deteccin de errores, etc. En la siguiente figura se muestra el formato de una trama o paquete de informacin correspondiente a la recomendacin IEEE 802.3 (Ethernet). Seguidamente, pasar a detallar el significado de cada campo de la misma:
51
Prembulo Inicio Direccin Direccin Longitud Datos Relleno Cdigo de redundancia de del del del campo trama destino origen de datos
7 Bytes 1 Byte 2 6 Bytes 2 6 Bytes 2 Bytes 0-1500 Bytes 46 Bytes 4 Bytes
Cada trama empieza con un prembulo de 7 bytes iguales (10101010). Esto genera en el receptor una onda cuadrada de 10 MHz, durante un tiempo de 5.6 seg, con el objeto de que el receptor se sincronice con el reloj del transmisor. Despus viene un byte llamado Inicio de trama (10101011), con el fin de marcar el comienzo de la informacin propiamente dicha. Los bytes correspondientes a la direccin de destino y de origen se utilizan para saber a quin va dirigido el mensaje y quin lo enva. Adems, existe un carcter especial que puede indicar que el mensaje va dirigido a un grupo de usuarios o a todos los usuarios. El byte que indica la longitud del campo de datos informa al receptor de cuntos bytes de informacin til o verdadera debe esperar a continuacin. Los datos corresponden bloques del archivo en particular que se desea enviar. Los bytes de relleno se emplean para garantizar que la trama total tenga una longitud mnima de 64 bytes (sin contar el prembulo ni el Inicio de trama). Esto se hace con el fin de desechar las tramas muy cortas (menores de 64 bytes) que puedan aparecer, como consecuencia de transmisiones abortadas por colisiones. El cdigo de redundancia sirve para hacer deteccin de errores. Si algunos bits de datos llegan al receptor errneamente (por causa del ruido o de una anmala ecualizacin), es casi seguro que el cdigo de redundancia ser incorrecto y, por lo tanto, el error ser detectado. A partir de ahora, vamos a particularizar este formato de trama IEEE 802.3 (Ethernet) para adaptarlo a las caractersticas propias de nuestro sistema.
52
Podemos ver arriba unas flechas rojas que indican los campos que van a desaparecer directamente por su inutilidad para la aplicacin que estamos llevando a cabo:
Dado que, como dije anteriormente, es imposible manipular las frecuencias de los relojes del transmisor y del receptor con un ajuste muy fino va software, el prembulo no tiene ningn sentido ya que suponemos conocidas de antemano dichas frecuencias de muestreo. Otra cosa distinta es que no estn muy parejas, pero en este caso ya indiqu las soluciones que bamos a adoptar para evitar los problemas derivados del desajuste en la sincronizacin (disminucin de la longitud de las tramas, etc). Adems, si echamos un vistazo al porqu de que este prembulo est compuesto por 7 bytes 10101010 (lo expliqu antes), no tiene ningn sentido considerarlo ya que nuestros relojes sern, en principio, de 44100 Hz, que no tiene nada que ver con los 10 MHz comentados anteriormente.
Las direcciones origen y destino no son, en absoluto, necesarias para nuestro propsito, pues slo tenemos un origen y un destino perfectamente determinados (transmisin unidireccional). Transmitiremos un fichero de un PC a otro de modo que origen y destino son nicos. Otra cosa distinta sera que estuviramos diseando una red de comunicaciones basada en este sistema de audio: en este caso, ya habra varios PCs, por lo que sera necesario disponer de los campos direccin de origen y destino para distinguir el PC de destino en el envo e identificar al PC origen como el PC que enva la informacin.
El relleno tambin voy a eliminarlo por la sencilla razn de que nuestro sistema no va a descartar tramas de longitud muy corta. Las tramas de poca duracin se sobreentender que corresponden colas de datos que quedan por enviar de un fichero y no cupieron en la trama anterior. As, este campo de relleno no lo tenemos en cuenta tampoco.
Por lo tanto, hemos pasado de una trama Ethernet tpica a una trama con la siguiente estructura:
Inicio de trama
1 Byte
Longitud Datos Cdigo de redundancia del campo de datos

2 Bytes 0-1500 Bytes 4 Bytes
53
He querido mantener el formato del Inicio de trama (10101011), para no alejarme mucho de la similitud que quiero mantener con las tramas Ethernet, aunque, a buen seguro, habra sido suficiente con una sola muestra, por ejemplo, de mxima amplitud o, incluso, nada, detectando el inicio de la trama a partir del campo que indica la longitud del campo de datos. El campo de datos de la trama no lo llegaremos a ocupar casi nunca con 1500 bytes. Esto es una exageracin en el caso de que tengamos problemas de sincronismo. Es decir, si existe un desajuste en las frecuencias de muestreo del transmisor y del receptor y transmitimos una trama de 1500 bytes (ojo, no bits), observaremos que la trama recibida tiene una forma adecuada en los bytes iniciales pero, luego, la degradacin es total pues la desincronizacin hace acto de presencia a lo largo del tiempo. Adems, si la trama tuviera 1500 bytes, calcular su cdigo de redundancia, eculizarla y demodularla va software dotara al sistema de una lentitud desesperante. Si nuestra aplicacin fuera hardware (como, por ejemplo, una tarjeta de Ethernet de 10 Mbps 100 Mbps), esto no sera un inconveniente pues sera mucho ms rpido. Por todo ello, la longitud del campo de datos deber ser, en general, menor que 1500 bytes. En el campo del cdigo de redundancia se inserta el CRC. El CRC se calcula en funcin de la direccin de destino, direccin fuente, campo de datos y un polinomio generador. El CRC es una de las herramientas ms comunes y potentes para la deteccin de errores. Dado un bloque de datos de k bits, el transmisor va a generar una secuencia de m bits, de forma que la trama resultante est formada por los k bits ms los m bits generados. Para generar este tipo de secuencias existen numerosos mtodos, como la aritmtica mdulo 2 y los mtodos polinmicos. El CRC se calcula realizando una divisin mdulo 2 de los datos entre un polinomio generador.
Los 3 polinomios generadores ms usados en la actualidad son los siguientes:
CRC-16 = x16 + x15 + x2 + 1 (usado en HDLC) CRC-CCITT = x16 + x12 + x5 + 1 CRC-32 = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 (usado en Ethernet)
54
La divisin que hay que realizar es la que muestro a continuacin:
Contenido de la trama
Polinomio generador
!" # #%$&#'()#01234

No usado
Aunque nosotros vamos a implementar esta divisin va software, la solucin hardware es mucho ms simple y potente. No lo voy a explicar aqu pero en cualquier libro de redes de ordenadores puede consultarse el hecho de que con puertas XOR y algunos registros de desplazamiento podemos realizar la divisin anterior. Cmo se hace con detalle la divisin?
Cdigo CRC:
5 5 5
Usa un polinomio generador El polinomio se representa mediante una cadena de (m+1) unos y ceros correspondientes a los coeficientes del polinomio. Generacin: o Se aaden tantos ceros a los datos como indique el grado del polinomio. o Se realiza la divisin mdulo 2 de los datos entre el polinomio generador. o El resto resultante es el CRC.
La deteccin de errores consiste en observar si el resto de dividir los datos junto con su cdigo CRC entre el mismo polinomio generador es
55
distinto de cero. Si es igual a cero, no hay errores, mientras que si es distinto de cero, hay errores.
En la divisin mdulo 2:
La resta se reduce a realizar la XOR. El cociente es 1 si la cifra ms significativa del dividendo es 1, si no, es 0.
Vamos a ver un ejemplo sencillo para aclarar los conceptos y facilitar la labor de posterior programacin en Matlab:
Polinomio generador: x3 + 1
1001
Datos: 110101
La divisin se hace as:
!"
56
Es importante dotar de celeridad computacional al sistema que estamos diseando. El clculo del CRC va software supone un obstculo a este propsito. A partir de las siguientes afirmaciones podremos determinar el CRC que emplearemos:
La longitud del campo de datos va a ser, en general, menor que 1500 bytes por lo que ya no tendr la obligacin de usar un cdigo de deteccin de errores muy potente. El parmetro de longitud del campo de datos ser configurable por el usuario. De esta forma, en entornos en donde la sincronizacin entre emisor y receptor sea perfecta, podremos formar tramas de hasta 1500 bytes, reduciendo esta cantidad drsticamente cuando exista un desajuste importante en las frecuencias de los relojes.
CRC-32 es computacionalmente ms complejo y lento que el CRC-16.
El CRC-16 tiene importantes caractersticas. Es capaz de detectar: o Errores simples o Errores dobles o Todos los nmeros impares de errores (1, 3, 5, 7, 9, ...)
y todo ello en una rfaga de 16 bits de longitud como mximo.
Adems, el 99.9984 % de otros patrones de error podrn ser detectados.
Los protocolos en el nivel de red y superior (modelo OSI-ISO para la interconexin de sistemas abiertos) usualmente utilizan un simple checksum para verificar que los datos transportados no se han corrompido debido al procesamiento en los distintos nodos. En nuestro caso, necesitamos algo mejor pues la transmisin del fichero en su totalidad debe hacerse sin errores. Un simple checksum no es tan potente como un cdigo de redundancia cclica. Definitivamente, lo ms coherente es que la transmisin se realice formando tramas de datos que transporten un CRC-16 que ocupa 2 bytes al final de las mismas. El resultado es importante para mejorar la velocidad de proceso.
3.2.6 Diseo del ecualizador o igualador de canal

Ahora me voy a centrar en una parte muy importante del sistema de transmisin de datos que tengo que disear: el ecualizador o igualador de canal.
57
Est situado en la cadena receptora. Se trata del primer bloque que aparece tras el canal de comunicaciones. Vemoslo en esta figura:
TX
CANAL h[n]
RX
ECUALIZADOR e[n]
El diseo del ecualizador, en principio, se puede abordar de muchas formas. Como dije en el comienzo de esta memoria, debera disear, dependiendo del nivel de ruido presente en el sistema, un filtro de Wiener, un igualador de cero forzado, un filtro inverso, etc. Adems, tendra la alternativa de dotarlo de carcter adaptativo, en el caso de que el canal fuese variante con el tiempo, o no. Un ejemplo de dnde es necesaria la ecualizacin adaptativa puede se la red telefnica conmutada (RTC), ya que dos factores contribuyen a la varianza temporal del canal: I. Las diferencias en las caractersticas de transmisin de los enlaces individuales que, posteriormente, hay que agrupar. II. Las diferencias en el nmero de enlaces dentro de una conexin.
El proceso de ecualizacin en este ejemplo debe ser adaptativo, es decir, el ecualizador tiene que ajustarse a s mismo continua y automticamente a partir de la seal de entrada. Sin embargo (y afortunadamente) ste no es nuestro caso, aunque pudiera parecerlo. Me explico. Cuando tratamos de calcular la respuesta impulsiva del sistema, el aspecto de la envolvente es siempre el mismo, pero la posicin de las muestras es distinta en cada caso. Realmente, no se trata de que nuestro canal sea variante con el tiempo (LTV), sino que este problema es consecuencia de otro ya de sobra conocido: el problema del sincronismo. Para apreciar tal efecto, una prctica muy buena es transmitir un tren de pulsos (deltas de Dirac) a travs del canal y observar lo que se registra en recepcin. Para ello, pues, hay que generar dicho tren de deltas; en Matlab, podemos hacerlo de la siguiente forma: 58
s=0; s(1:7000:300000)=1;
sound(s,44100,16)
%inicializacin %tren de deltas espaciadas 7000 muestras %transmisin a 44100 Hz y 16 bits
En este ejemplo, la separacin entre deltas es de 7000 muestras o, equivalentemente, 7000/44100 = 0.1587 seg. Transmitimos el tren y lo registramos en la otra tarjeta (o en la misma, si es full-duplex). El resultado, visto en Cool Edit, es el siguiente:
Qu es lo que ha ocurrido? No se trata de que el canal sea variante con el tiempo (LTV) sino que es una muestra ms del desajuste en las frecuencias de muestreo. La sincronizacin no es perfecta y, por tanto, los instantes de muestreo se mueven a lo largo del tiempo. Por lo tanto, es un problema interno en los relojes del transmisor y del receptor, y no tiene nada que ver con que el canal digital de comunicaciones sea LTV. Para corroborarlo, vamos a observar dos impulsos del tren de deltas recibidas (eligir casos extremos: dos que, en la figura de arriba, parecen tener mnima (I) y mxima (II) amplitud y a priori, respectivamente):
59
Figura I:
Figura II:
Efectivamente, la respuesta impulsiva tiene, formalmente, igual envolvente en ambos casos extremos, habindose producido un desplazamiento de las muestras. Sin ayuda
60
de este zoom realizado, podra parecer que las amplitudes de las envolventes son distintas pero, sin embargo, no es as: se trata del mismo efecto ptico que observamos cuando estuvimos hablando del problema del sincronismo (ms concretamente, clculo del desajuste de frecuencias de muestreo). En consecuencia, el filtro ecualizador ser no adaptativo. En ltima instancia, podra hacerse un filtrado adaptativo va hardware, pero esto ya se sale de nuestro objetivo. Por otra parte, hay que considerar la posibilidad de que el ruido sea o no importante para disear un filtro de Wiener o, por el contrario, entrar directamente en la realizacin de un filtro inverso, de cero forzado o ecualizador tapped-delay-line, etc. Del anlisis de ruido del sistema del punto 3.1 de la memoria (Anlisis y caracterizacin del canal de comunicaciones), concluimos que el ruido no es tan relevante como para tenerlo en cuenta en el diseo y realizacin del igualador de canal. De cualquier forma, si por algn motivo, como puede ser, por ejemplo, que el cable no sea de buena calidad o de una longitud excesivamente grande, aparece algo ms de ruido y la seal se atena en exceso, el propio igualador podr compensarlo porque el aumento de ruido, a buen seguro, no ser muy grande, siempre que el cable de audio no sea de nfima categora. Si el cable es muy largo no hay problema, pues, lo que haramos sera utilizar ms potencia en el transmisor y en el receptor, ajustando adecuadamente los controles de reproduccin y grabacin, respectivamente, como expliqu en su momento. El objetivo en todo momento ser mantener en unos niveles adecuados la relacin seal a ruido (SNR), para lo cual existen numerosos mtodos. Vamos a centrarnos ya en el diseo propiamente dicho del ecualizador. En el receptor del sistema, la seal recibida es demodulada y sncronamente muestreada para decidir qu smbolo, de los M posibles de una transmisin M-aria PAM, se transmiti. En principio, el nmero de niveles de amplitud est limitado por los fenmenos de dispersin que dan lugar a la aparicin de ISI: en general, la ISI limita el nmero de niveles de amplitud detectables. Por consiguiente, la ISI es un factor que limita la tasa de transferencia del sistema. Afortunadamente, nuestra ISI no es muy importante pues el criterio de Nyquist se cumple con bastante holgura: 44.1 KHz > 220 KHz. Sin embargo, para compensar esta pequea distorsin intrnseca que provoca la interferencia entre smbolos, tenemos que ecualizar: el propio ecualizador debe resolver por s mismo los problemas de sincronismo e ISI (aunque en nuestro caso no sean determinantes). El problema que tenemos es ste:
d[n]
CANAL h[n]
u[n]
IGUALADOR g[n]
y[n]
61
En nuestro sistema, el ruido presente es muy pequeo, por lo que la SNR es muy alta. Conocer este dato es fundamental pues nos muestra la opcin ms interesante de entre todo el abanico de ecualizadores de canal posibles. En canales buenos, en donde la SNR es grande, como, por ejemplo, en canales telefnicos, se suele usar el igualador de cero forzado (ZF: Zero-Forcing Equalizer). Los errores son debidos principalmente al truncamiento del canal: si el ancho de banda fuera muy grande no habra problemas, pero en nuestro caso (20 KHz aprox.), el canal recorta el pulso en frecuencia, provocando el ensanchamiento temporal del pulso, dando lugar a la aparicin de ISI. El hecho de disear el igualador ZF es, precisamente, para cancelar esta ISI. Tericamente se lleva a cabo el diseo para eliminar las 2 partes que tiene la ISI: causal (posterior al instante de muestreo) y no causal (anterior al instante de muestreo); sin embargo, en la prctica, se causaliza siempre. Nuevamente, en nuestro caso la ISI no es muy importante, por lo que este diseo es ms ptimo de lo que podramos pensar inicialmente. Bsicamente, pretendemos que h[n]*g[n]=[n], donde h[n] es la respuesta impulsiva del canal (cable de audio) y g[n] es la respuesta impulsiva del igualador de cero forzado que vamos a disear. Desarrollando la convolucin, tenemos esto:
M 1 k =0
g[k ]h[n k ] =[n]
(o [n-n0], si admitimos un pequeo retraso)
que, matricialmente, podemos verlo as:
Ax = b
62
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster h[0] h[1]
0 h[0]

0 0
0 0 0
0 0 0 0 h[0]
0 0 0 0 0 h[0]

0 0 0 0 0 0
0 0 0
g[0] g[1]
h[N-1] h[N] 0
h[N-2] h[N-1] h[N] 0
h[N-1]
h[0] h[1] h[N-2]
0 0
1 0
0 h[0]
g[M-2]
h[N]
h[N-1]
h[N-2]
g[M-1]
La resolucin de este sistema matricial de ecuaciones se consigue con el uso de la pseudoinversa. Tenemos un sistema cuyas dimensiones es la siguiente: A x = b
{[N+M-1]x[M]} {[M]x[1]} = {[N+M-1]x[1]} lo cual nos impide invertir directamente la primera matriz. La tcnica de usar la pseudoinversa consiste en multiplicar por A T a ambos lados de la ecuacin y nos permite resolver el sistema:
x= A A
A b
63
El igualador de cero forzado es ptimo en nuestra aplicacin porque el ruido no es un inconveniente insalvable, sino todo lo contrario. Este ecualizador trata de calcular la respuesta inversa del canal, de forma que, si hubiera mucho ruido, la degradacin sera extrema, pero este no es el caso. Se llama de cero forzado (zero-forcing equalizer) porque impone que el pulso de transmisin sea cero justo por los instantes adyacentes al instante de muestreo en el receptor. Los resultados prcticos que arroja este igualador son ptimos. Para corroborarlo, voy a mostrar el resultado de ecualizar la respuesta impulsiva del canal en el peor de los casos, es decir, cuando no cae una muestra en todo lo alto sino que caen dos en los extremos laterales, como vimos en la figura I anterior (falta total de sincronismo). La convolucin de la respuesta impulsiva del canal y la respuesta impulsiva del ecualizador debe ser lo ms parecida posible a una delta de Dirac, lo cual indicara que el conjunto canal+ecualizador se comportara como un canal de comunicaciones ideal, es decir, con una respuesta en frecuencia totalmente plana a lo largo de la mayor parte del ancho de banda disponible. Las siguientes figuras de Matlab muestran cmo se realiza la ecualizacin visualmente de forma continua (no muestra a muestra):
64
El resultado es, como era de esperar, prcticamente un impulso, dada la optimalidad que nos aporta la eleccin de un igualador de cero forzado (ZF) en nuestro sistema, an cuando, como digo, ste es el caso ms desfavorable. En los casos normales, se obtiene una delta de Dirac perfecta. Como dije antes, presentar todo el cdigo Matlab en el prximo bloque. Esto ha sido un adelanto para que, cuando lleguemos al bloque de programacin, est claro qu vamos a hacer realmente.
3.2.6.1 Insercin de seales piloto entre tramas

Para que la ecualizacin de tramas sea perfecta, necesitamos dar un paso ms. El hecho de que los relojes del transmisor y del receptor no funcionen exactamente a la misma frecuencia nos obliga a introducir seales piloto entre una trama y la siguiente, a lo largo de toda la transmisin. Estos pilotos nos indican el estado de sincronizacin de la trama posterior. A partir de estas seales podremos determinar el ecualizador ptimo en cada caso. Esto es as porque la falta de sincronismo provoca, como ya he explicado en este apartado 3.2.6, un movimiento de muestras a lo largo del tiempo que, a su vez, podemos interpretar como una ligera modificacin en el canal de comunicaciones. Ya coment que el causante de este efecto era el desajuste frecuencial y en absoluto se trataba de que el canal fuera variante con el tiempo (LTV). Lo que s es cierto es que se trata de un igualador dinmico (no esttico). La insercin de estos impulsos es ms importante de lo que puede parecer a priori: es fundamental para que el sistema de recepcin pueda alinearse o engancharse correctamente a las tramas para, posteriormente, demodularlas con xito. 65
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster tramas:
Hay que resaltar las grandes ventajas que supone introducir estos pilotos entre Permite hacer la separacin previa de tramas.
Dado que es un impulso (mxima amplitud), en recepcin tendremos la respuesta impulsional del canal para cada trama, justo unos instantes antes. Esta respuesta a priori es distinta para cada paquete de informacin habida cuenta de la desincronizacin que puede existir. Por lo tanto, cada trama debe ecualizarse independientemente de las dems. Es a partir de este impulso recibido de donde se extraer el mejor igualador de canal para la trama posterior a dicho impulso.
Es interesante ver qu ocurre grficamente. Supongamos datos procedentes de un fichero listos para ser transmitidos por el canal con la siguiente configuracin bsica: Tramas cuyo campo de datos tiene una longitud de 100 bytes. Modulacin M-aria con M=8 niveles de amplitud distintos. N=8 muestras por smbolo.
En esta imagen he extrado una trama y he sombreado en color blanco la seal piloto previa a la trama 8-aria. Al final de la misma est presente el piloto del siguiente paquete de informacin.
66
Como he dicho, aparte de permitirnos el alienamiento a las tramas para separarlas, nos facilita enormemente la extraccin del igualador ptimo. Este igualador, claro est, es el comentado igualador de cero forzado dinmico, actualizable trama a trama a partir de la seal piloto inicial que, en recepcin, degenera en la respuesta impulsiva del canal. Voy a explicarlo con ms detalle desde el punto de vista de la cadena de recepcin. La insercin de seales piloto nos facilita enormemente 2 tareas fundamentales. A saber:
Nos permite hacer una ecualizacin o igualacin de canal casi perfecta independientemente de los problemas de sincronismo pues, de hecho estos problemas se solucionan gracias a que: o Hemos disminuido la longitud de las tramas o La delta absorbe los problemas de sincronismo pues se basa en que considera que el canal es distinto para cada trama. Es decir, para cada trama tenemos una respuesta impulsiva del sistema distinta debido al desajuste en las frecuencias de muestreo cuando, realmente, el canal es el mismo canal LTI no variante con el tiempo.
El alineamiento a los datos e, individualmente, el alineamiento a cada trama se facilitan enormemente gracias a que previamente existe un piloto.
Observemos, a continuacin, parte de un fichero recibido estructurado en tramas. Tenemos una parte inicial sin datos hasta la recepcin del primer impulso. En la figura podemos apreciar 3 tramas y parte de una cuarta trama:
67
Entre tramas tenemos pilotos que nos permitirn hacer la separacin de tramas para, posteriormente, ecualizarlas y extraer los datos que nos interesan del fichero origen que deseamos transmitir. se es el objetivo a cumplir.
3.2.7 Interleaving
Para concluir este bloque, voy a hacer referencia a un procedimiento frecuentemente utilizado en muchas aplicaciones de transmisin de datos en donde los datos se estructuran en tramas. Se trata del entrelazado de bit o, en ingls, interleaving: consiste en modificar sensiblemente el envo de tramas de una manera un tanto particular. Cuando se ha completado la formacin de las tramas, podemos enviarlas tal cual, una detrs de otra, pero tambin podemos entrelazarlas. Es decir, en vez de transmitir todos los datos de una trama, podemos transmitir los datos procedentes de todas las tramas a la vez, estructurados en una nueva trama. Estas nuevas tramas contienen datos de todas las tramas formadas con anterioridad. El objetivo es que si hay errores en la transmisin de una trama, estos no afecten en su totalidad solamente a dicha trama en concreto, sino que afecten a todas las tramas pero de una forma menos contundente. En definitiva, se trata de no permitir que un error importante destroce a una sola trama, sino que afecte en menor medida a todas ellas, pues se han entrelazado. En nuestra aplicacin, he decidido no incluir este procesamiento de datos adicional, debido a los dos siguientes motivos: I. El sistema es suficientemente bueno como para mejorarlo an ms de cara a la aparicin de errores puntuales en ciertas tramas que el entrelazado pueda suavizar. II. Supone un inconveniente muy importante en la velocidad de proceso. Es decir, el sistema est implementado va software en su totalidad. Aadir un bloque nuevo de entrelazado de tramas supone un incremento notable de la lentitud. Adems, este bloque debera aparecer tanto en el transmisor como en el receptor, ya que habra que recomponer todas las tramas entrelazadas que el transmisor envi.
68
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster Grficamente, el entrelazado consiste en lo siguiente:
TRAMA
TRAMA
TRAMA
TRAMA
TRAMA
N-1
TRAMA
TRAMAS A ENVIAR REALMENTE

Esto es lo que realiza: a partir de las tramas 1 ... N forma nuevas tramas que son las que se transmitirn realmente. Concluyo reafirmando que esto no es necesario para nuestra aplicacin, pues, adems, supone un obstculo en la velocidad de procesamiento de los datos, tanto en el transmisor como en el receptor.
69
3.3 PROGRAMACIN EN MATLAB DEL MODULADOR Y DEMODULADOR

Ya estamos en disposicin de realizar la programacin estructurada de los distintos bloques que forman la cadena de transmisin y la cadena de recepcin. Casi la totalidad del proyecto se ha implementado en Matlab de forma que la mayor parte de las explicaciones las realizar precisamente sobre cdigo Matlab (ficheros .M). Tratar de seguir de la forma ms estricta posible el siguiente mtodo:
Me ceir al orden del propio sistema de transmisin, de manera que empezar por el transmisor y terminar en el receptor.
La explicacin ser bloque a bloque siguiendo el orden anterior, detallando todos los subbloques que hay en las cadenas de transmisin y de recepcin.
Siempre: o En primer lugar, expondr cul ser la funcionalidad de cada bloque. o En segundo lugar, mostrar todo el cdigo Matlab del bloque correspondiente. o Por ltimo, explicar oportunamente el cdigo anterior.
Utilizando Matlab, se programarn, entonces, los sistemas modulador y demodulador. Las pruebas las he realizado tomando como base archivos de audio (.WAV) que reproduzco con una tarjeta y registro por la otra (o, como siempre, con la misma, si es una tarjeta con caractersticas full-duplex, como ya expliqu al principio del proyecto). Sin embargo, en el listado definitivo, desaparecen los pasos intermedios referentes a la formacin de ficheros .WAV para, directamente, tomar el control de la tarjeta de sonido mediante los drivers adecuados. Todos los ajustes llevados a cabo han sido necesarios para obtener unas prestaciones parecidas a las deseadas en el estudio terico del bloque anterior.
Por consiguiente, comienzo por la cadena transmisora:
70
3.3.1 Cadena transmisora
3.3.1.1 Programa principal

Para empezar con cdigo Matlab, en primer lugar, vemos el programa principal o main de la cadena de transmisin:
function main clc disp(' ') Proyecto Fin de Carrera') disp(' disp(' ') TRANSMISIN DE DATOS MEDIANTE SOUNDBLASTER') disp(' disp(' ') disp(' ') disp('AUTOR: Juan Francisco Izquierdo Len') disp('DIRECTOR: Jos Ramn Cerquides Bueno') disp('----------------------------------------------------------------') disp('----------------------TRANSMISOR--------------------------------') disp('----------------------------------------------------------------') fichero=input('Introduzca el fichero que desea transmitir: ','s'); M=input('Nmero de niveles de la modulacin PAM (M=2/4/8/16): '); N=input('Nmero de muestras por smbolo (N par): '); BDT=input('Longitud (bytes) del campo de datos de las tramas Ethernet: '); FSAM=input('Frecuencia de muestreo (Hz): '); NB=input('Resolucin (8 16 bits): '); dat=transmitefichero(M,N,BDT,fichero); disp('PULSE CUALQUIER TECLA PARA TRANSMITIR EL FICHERO...'); pause; playsnd_nt(dat',FSAM,NB); disp('-----------------FICHERO TRANSMITIDO----------------------------') disp('----------------------------------------------------------------')
71
Con la ayuda de la funcin input de Matlab, se solicita la entrada de datos al usuario. Estos datos son los siguientes: a. Ruta y nombre del fichero a transmitir b. Nmero de niveles de la modulacin M-PAM (2, 4, 8 16) c. Nmero de muestras necesarias para la codificacin de un smbolo (N par) d. Longitud en bytes del campo de datos de las tramas Ethernet que hay que formar e. Frecuencia de muestreo (Hertzios) f. Resolucin en bits de la tarjeta de sonido (8 16)
Seguidamente se llama a la funcin transmitefichero, en donde procesaremos los datos adecuadamente para, posteriormente hacer la transmisin a travs del cable de audio con el driver playsnd_nt, cuyos argumentos son los datos a transmitir que regres la funcin transmitefichero y, adems, la frecuencia de muestreo y la resolucin en bits (nmero de bits empleados para codificar el valor de una muestra).
3.3.1.2 TransmiteFichero
En esta cadena, deberemos realizar un tratamiento de los datos que queremos transmitir. Partiremos de un fichero de un datos que tenemos que enviar y formaremos un archivo de audio que cumple todas las caractersticas necesarias de acuerdo con el estudio terico. Mostrar el cdigo completo del programa principal y, posteriormente, desgranar cada parte por separado. Pienso que es la mejor forma de que el lector comprenda rpidamente lo que quiero exponer.
function out=TransmiteFichero(M,N,BDT,fichero) %M: modulacin M-ARIA %N: nmero de muestras por smbolo %BDT: bytes de datos por trama %fichero: el que queremos transmitir %f: frecuencia de muestreo
72
%nb: resolucin en bits de la tarjeta de sonido disp('PROCESANDO FICHERO. POR FAVOR, ESPERE...'); fid=fopen(fichero,'r'); B=BDT; [a,count]=fread(fid,B); y=[1,zeros(1,50)]; while count>0 b=dec2bin(a,8); a=reshape(b',[1,count*8]); i=1; j=i+count*8-1; trama=Ethernet(dec2bin(count,16),a(i:j)); while rem(length(trama),log2(M)) trama=[trama,'0']; end trama8=Modulador(trama,M); y=[y,Transmisor(trama8,N/2),zeros(1,30),1,zeros(1,50)]; i=j+1; [a,count]=fread(fid,B); end %wavwrite(y,44100,'c:\jf\tx\tx.wav'); %playsnd_nt(y',f,nb); out=y;
Esta funcin principal tiene 4 argumentos de entrada y uno de salida:

function out=TransmiteFichero(M,N,BDT,fichero)
M es el nmero de niveles que deseamos tener en nuestra transmisin. Por ejemplo, si deseamos que la transmisin sea 8-PAM, es decir, con 8 niveles diferentes de amplitud, pasaremos el parmetro de entrada M=8.
N es el nmero de muestras por smbolo. Como usaremos el cdigo de lnea Manchester explicado con anterioridad, tendremos N/2 muestras con un nivel de los M posibles y las otras N/2 muestras con el mismo nivel pero cambiado de signo.
BDT es el nmero de bytes de datos que queremos transmitir en cada trama. Por ejemplo, en las tramas Ethernet IEEE 802.3, el mximo es 1500 bytes; sin embargo, ya dije que, debido a varios problemas, nuestra longitud de trama probablemente sera bastante inferior.
fichero es una cadena de caracteres que contiene la ruta y el fichero que se desea transmitir. 73
out es la matriz de datos que enviaremos a la tarjeta de sonido para realizar la transmisin.
El primer paso es abrir el fichero que deseamos transmitir. Esto se hace con la funcin fopen, que nos devuelve un identificador de fichero nico. Hay que tener en cuenta que, en cada iteracin, manejaremos solamente BDT bytes de dicho fichero y, por lo tanto, lo mejor es no abrirlo completamente, sino leer los bytes que tengamos que procesar en ese momento (BDT como mximo). La funcin fread nos devuelve una matriz (a) con los datos binarios ledos y el nmero de bytes ledos con xito (count). A continuacin, se forma la matriz de datos que tenemos que transmitir: se genera a partir del fichero de datos de partida y, por consiguiente, dado que ste no se lee completamente, habr que realizar un bucle (while) hasta que dicho fichero sea ledo en su totalidad. Cuando realizamos una lectura con fread, sta funcin nos devuelve una matriz columna de nmeros decimales en el rango de 0 a 255. Es obligado, por tanto, tener nuestro fichero organizado en cadenas de bits (0s y 1s). Para ello, el primer paso es pasar de la matriz columna de nmeros decimales a otra matriz columna de nmeros binarios. La funcin que realiza esta conversin a binario es dec2bin:
b=dec2bin(a,8); %fichero organizado en filas de bytes
El segundo argumento (8) es para conseguir nmeros binarios de 8 cifras, es decir, bytes (XXXXXXXX). Esto es necesario pues si el nmero decimal es menor que 128, el correspondiente nmero binario slo tendra 7 bits. Por ltimo, debemos recomponer el fichero en una sola cadena de bits, de forma que ya podemos apreciar el fichero completamente binario. Para ello, utilizamos la orden reshape, que realiza una modificacin en las dimensiones de la matriz:
a=reshape(b',[1,count*8]); %cadena de bits que quiero transmitir
O sea, que transponemos la matriz columna cuyas filas son bytes (b), y le damos la dimensin de una sola fila de longitud count*8, que es el tamao inicial expresado en bits (recordemos que count era el nmero de bytes ledos con xito del fichero).
74
Voy a poner un ejemplo para aclarar esto con un fichero inventado de 5 bytes. Supongamos que lo abrimos y lo leemos, obteniendo la siguiente matriz de nmeros decimales:
23 255 a= 0 34 7
Con la ayuda de dec2bin, la convertimos fila a fila en binaria, es decir:
00010111 11111111 b = 00000000 00100010 00000111
Por ltimo, la reordenamos convenientemente mediante la funcin reshape:
a=[0001011111111111000000000010001000000111]
As, ya disponemos del fichero organizado en una fila de bits, totalmente preparados para ser enviados en tramas.
75
Las ltimas instrucciones del programa principal son bsicamente stas:

trama=Ethernet(dec2bin(count,16),a(i:j)); trama8=Modulador(trama,M); y=[y,Transmisor(trama8,N),zeros(1,30),1,zeros(1,50)]; (*)
y permiten:
La formacin de la trama Ethernet correspondiente. La longitud de dicha trama es count bytes (los que lemos inicialmente).
Realizar la modulacin de la trama correspondiente de acuerdo con el nmero M deseado de niveles.
Y, por ltimo, hacer la transmisin teniendo en cuenta que la codificacin de lnea debe ser la codificacin Manchester.
Todos estos pasos hay que realizarlos mientras quede algo por leer del fichero (count>0). Por esta razn, al final del bucle, para formar la siguiente trama, se realiza la lectura de otro bloque de BDT bytes del fichero de datos; el ltimo bloque tendr, casi con toda probabilidad, menos de BDT bytes del fichero de datos, aunque pudiera tener BDT si es tamao del fichero es mltiplo de BDT. Finalmente, la funcin devuelve out, que contiene todos los datos que transmitiremos en el formato adecuado: M-ario, cdigo Manchester, N muestras/smbolo y organizado en tramas Ethernet.
Conclusin: A partir de un fichero de datos que deseamos transmitir, hemos generado una matriz compuesta por la agrupacin de todas las tramas formadas. Esto es lo que reproduciremos (transmitiremos) en el PC de origen (en su tarjeta de sonido correspondiente) y registraremos (recibiremos) en el PC de destino, con la ayuda de algunos drivers .dll de Matlab para el manejo de audio.
(*) zeros(1,30),1,zeros(1,50) es el piloto existente entre una trama y la siguiente. Recordemos la enorme utilidad que tena para separar tramas y ecualizarlas adecuadamente.
76
Ahora paso a desgranar, bloque por bloque, la cadena de transmisin:
TRANSMISOR
{bk} Modulador de amplitud de pulso (PAM) {ak} Filtro transmisor g(t) s(t)
Lo explicar por orden:
I. Formacin de tramas II. Modulador III. Transmisor
3.3.1.2.1 Formacin de tramas

En este apartado, introducir el cdigo Matlab necesario para la formacin de tramas Ethernet. Recordemos las variaciones que debamos introducir:
eliminacin de algunos campos
cambio del CRC-32 por CRC-16
disminucin de la longitud del campo de datos por los problemas de sincronismo
etc.
77
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster El cdigo es el siguiente:
function[t]=Ethernet(long,datos) %Funcin que forma una trama Ethernet IEEE 802.3 %long es la longitud del campo de datos %preambulo=[dec2bin(170),dec2bin(170),dec2bin(170),dec2bin(170),dec 2bin(170),dec2bin(170),dec2bin(170)]; preambulo=[]; inicio_trama=dec2bin(171); longitud_datos=long; %relleno=dec2bin(0,46*8); %46 bytes de relleno %CRC crc=CalculaCrc(datos,16); %CRC-16 t=[preambulo,inicio_trama,longitud_datos,datos,crc]; formada
%trama
Esta funcin tiene dos entradas:
long: marca la longitud del campo de datos. En el programa principal se hace la llamada a esta funcin con long convertido ya a binario, por lo que no tendremos que hacer la conversin aqu.
datos: es la cadena de bits de datos que van a llenar la trama Ethernet.
Podemos observar que originalmente consider el campo prembulo pero posteriormente lo descart por su inutilidad en nuestro caso (como ya expliqu), de la misma forma que el campo relleno. La trama comienza con un inicio de trama 10101011, como indica la recomendacin IEEE 802.3. Esto no es ms que el nmero 171 en decimal y por ello se realiza la conversin con dec2bin. Ya coment anteriormente que podramos haber elegido otro inicio de trama distinto (y ms sencillo que ste, por qu no decirlo), aunque lo mantengo por no separarme tericamente de la recomendacin Ethernet. A continuacin, tenemos longitud del campo de datos, es decir, el parmetro long de entrada, seguido de los datos propiamente dichos (el otro parmetro de entrada).
78
Como el campo relleno lo he eliminado, lo nico que nos queda es el campo de Cdigo de Redundancia Cclica o CRC, que nos serva para llevar a cabo la deteccin de errores. En conclusin, tenemos la estructura de trama que ya vimos anteriormente:
Inicio de trama
1 Byte
Longitud Datos Cdigo de redundancia del campo de datos

2 Bytes 0-1500 Bytes 4 Bytes
3.3.1.2.1.1 Computacin del CRC en Matlab
Hay varias formas de realizar la computacin del CRC en Matlab. Entre ellas destaca el uso de las funciones de los campos de Galois (Galois Field Computation) del Toolbox Communication de Matlab. Sin embargo, yo he optado por escribir el cdigo partiendo de cero, simulando la divisin mdulo 2 que hay que realizar manualmente. Esto me aporta una mejor portabilidad futura en el sentido de que slo habra que elegir otro polinomio generador distinto al CRC-16 (CRC-CCITT o CRC-32, entre otros), lo cual ya est disponible en la funcin que he creado, y, adems, no aumenta la velocidad, sino todo lo contrario, ya que evita llamar a funciones externas, que hacen que la ejecucin del cdigo sea ms lenta. Adems, nunca est dems, comprender el funcionamiento interno de un CRC y esto se puede conseguir programando de forma independiente, como lo voy a hacer yo.
La funcin que extrae el cdigo de redundancia cclica a los datos es la siguiente:
function[y]=CalculaCrc(datos,n) %Esta funcin calcula el CRC de los datos de la trama Ethernet, %"datos", utilizando un polinomio generador de n bits if n==32 %CRC-32
79

1 1];
x=[1 0 0 0 0 0 1 0 0 1 1 0 0 0 0 0 1 0 0 0 1 1 1 0 1 1 0 1 1 0 1 else %CRC-16 x=[1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1]; end lx=length(x); data=[datos,dec2bin(0,lx-1)]; d=string2mat(data); ld=length(d); i=1; daux=d(i:i+lx-1); while i+lx<=ld if daux(1)==1 aux=xor(daux,x); daux=[aux(2:lx),d(i+lx)]; else daux=[daux(2:lx),d(i+lx)]; end i=i+1; end if daux(1)==1 aux=xor(daux,x); else aux=daux; end y=mat2string(aux(2:length(aux)));
La funcin CalculaCrc tiene dos parmetros de entrada:
datos: los datos extrados del fichero que van a llenar el campo de datos de la trama Ethernet.
n: es un nmero entero. Puede tomar dos valores: 16 32. o Si n=16, el CRC que va a calcular es el CRC-16 o Si n=32, el CRC que va a calcular es el CRC-32 o Evidentemente, si dentro de la funcin se indica otro polinomio generador distinto como, por ejemplo, el CCITT u otro cdigo Hamming que permita la correccin de errores, podra hacerse que n tomara ms valores para tener en cuenta a los nuevos polinomios.
Lo primero que realiza la funcin es determinar, gracias al valor de n, el polinomio generador necesario para calcular el CRC. Este polinomio ser el divisor de la divisin mdulo-2, cuyo dividendo sern los datos (cadena de bits de la trama Ethernet pasada como parmetro en datos). El cociente de esta divisin no se utiliza para nada, pero el resto es esencial: es el CRC que hay que aadir en el campo Cdigo de redundancia de la trama Ethernet.
80
La divisin, paso a paso, se calcula de la forma que indiqu en el ejemplo del bloque 3.2.2 Estructuracin de los datos. Formacin de tramas:
Se aaden tantos ceros a los datos como indique el grado del polinomio generador (lx-1).
Recordemos que en la divisin mdulo 2:
La resta se reduce a realizar la XOR.
El cociente es 1 si la cifra ms significativa del dividendo es 1, si no, es 0.
La funcin lgica XOR(A,B) (OR exclusiva) es la resta lgica simtrica (sin acarreo) de los elementos de A y B:
El resultado es 1 cuando cualquiera de los dos, A o B, pero no ambos, es distinto de cero.
El resultado es 0 cuando A y B son ambos 0 o ambos distintos de 0.
A y B deben tener las mismas dimensiones.
La tabla de verdad es, en consecuencia, la siguiente:
A 0 0 1 1
B 0 1 0 1
XOR (A,B) 0 1 1 0
81
Todo esto es lo que realiza el cdigo que he presentado antes:
Si daux (cifra ms significativa del dividendo) es igual a 1, el cociente es 1
Si no, entonces el cociente es igual a 0
aunque como puede observarse en el listado, el cociente no aparece para nada, dada su nula importancia en el clculo del CRC.
Podemos apreciar en el cdigo que hay dos funciones completamente nuevas:
string2mat
mat2string
Son dos funciones necesarias y que me he visto obligado a crear por la siguiente razn: en Matlab, no es lo mismo x=[1 0] que x=10, es decir, como ocurre en C, no es lo mismo una matriz fila de datos que una cadena de caracteres. Por lo tanto, dado que las funciones lgicas en Matlab trabajan con matrices y no cadenas, hay que hacer las conversiones oportunas. En un principio, decid trabajar con cadenas y no con matrices, entre otras razones, por cuestiones referentes a la legibilidad y a la claridad en Matlab. Por lo tanto, si los datos que le pasamos como parmetros a CalculaCrc tienen el formato de cadena, con la ayuda de string2mat, permitimos la conversin al formato de matriz, de forma que las funciones lgicas ya pueden operar con ellos. De la misma forma, tras haber hecho todos los clculos del CRC, deberemos hacer el paso contrario, es decir, los datos en formato matriz los convertiremos a formato cadena, con la ayuda de mat2string:
y=mat2string(aux(2:length(aux)));
Voy a limitarme en este punto a mostrar los listados de ambas funciones en Matlab, obviando su explicacin, pues son bastante intuitivos y fciles de entender:
82
function[y]=string2mat(x) %Convierte una cadena de caracteres en una matriz fila de datos y=[]; i=1; while i<=length(x) y=[y,str2num(x(i))]; i=i+1; end ------------------------------------------------------------------------function[y]=mat2string(x) %Convierte una matriz fila de datos en una cadena de caracteres y=''; for i=1:length(x) y=[y,int2str(x(i))]; end
str2num (convierte una cadena en un nmero) e int2str (convierte un entero en una cadena) son funciones propias de Matlab. La variable aux es la que contiene el CRC resultante, pues es el resto final de la divisin mdulo-2 completa. Como apunte final, notar 2 cosas: 1) El formato de matriz fila de los polinomios generadores se ha conseguido trasladando los exponentes de los mismos a las posiciones correspondientes de la matriz. Por ejemplo, si el polinomio generador es x3+x+1, en el cdigo Matlab de la funcin CalculaCrc debe aparecer x=[1(por x3) 0(por x2) 1(por x1) 1(por x0)]; 2) El uso de un CRC u otro es totalmente configurable por el usuario. Yo he colocado los ms usados pero no quiere decir que sean los nicos y, por lo tanto, el usuario puede incluir otros cdigos de redundancia distintos, de acuerdo con sus necesidades.
3.3.1.2.2 Modulador
En este bloque se realiza la modulacin de los datos. Ya hemos formado la trama Ethernet correspondiente, de forma que el siguiente paso, antes de realizar la transmisin 83
propiamente dicha, es modularlos siguiendo los criterios establecidos. Estos criterios se dedujeron en el estudio terico inicial. Bsicamente podamos resumirlos en que la transmisin se iba a realizar:
en banda base, salvando la absorcin del nivel de continua por parte del canal a travs de la codificacin de lnea Manchester
con un modulador de amplitud de pulso (PAM: Pulse-Amplitude Modulator) con modulacin M-aria, dejando como parmetro libre el nmero M de niveles de amplitud (configurable por el usuario) a 2, 4, 8 16, de forma que la velocidad de transmisin y el tratamiento de errores quedaran optimizados
y, adems, la correspondencia entre bits y smbolos no iba a ser binaria natural sino Gray, con objeto de disminuir la probabilidad de error de bit (BER)
Todo esto lo realiza el bloque modulador, va software (como todo el proyecto), a travs de la funcin Modulador que, a continuacin, muestro:
function[c]=Modulador(tramaIEEE,m) j=1; i=1; c=[]; if(m==2) %8-PAM %Formacin de trama de 2 niveles (0,1) while i<=length(tramaIEEE) c(j)=Gray_Code(bin2dec(tramaIEEE(i:i+0))); los nmeros en 2 niveles (0,1) j=j+1; i=i+1; end c=(c-0.5)/0.5; elseif(m==4) %4-PAM %Formacin de trama de 4 niveles (0...3) while i<=length(tramaIEEE) c(j)=Gray_Code(bin2dec(tramaIEEE(i:i+1))); los nmeros en 4 niveles (0...3) j=j+1; i=i+2; end c=(c-1.5)/1.5; elseif(m==8) %8-PAM %Formacin de trama de 8 niveles (0...7) while i<=length(tramaIEEE) c(j)=Gray_Code(bin2dec(tramaIEEE(i:i+2))); los nmeros en 8 niveles (0...15) j=j+1; i=i+3;
%c es la cadena con
%c es la cadena con
%c es la cadena con
84
end c=(c-3.5)/3.5; elseif (m==16) %16-PAM %Formacin de trama de 16 niveles (0...15) while i<=length(tramaIEEE) c(j)=Gray_Code(bin2dec(tramaIEEE(i:i+3))); los nmeros en 16 niveles (0...15) j=j+1; i=i+4; end c=(c-7.5)/7.5; end
%c es la cadena con
Debemos, por lo tanto, modular la trama IEEE ya formada con anterioridad en el bloque de formacin de tramas, con un nmero de niveles de amplitud determinado. La funcin Modulador tiene dos parmetros de entrada:
tramaIEEE: es la trama Ethernet que formamos en el bloque anterior (inicio de trama + longitud del campo de datos + datos + cdigo de redundancia)
m: es el nmero M de niveles de amplitud que va a generar a su salida el modulador M-PAM
He realizado el listado teniendo como objetivo principal la optimizacin de la tasa de transferencia y la probabilidad de error, por lo que he dejado a M como parmetro libre (2, 4, 8 16) para el usuario. El fundamento de un modulador M-ario, en donde M=2k, es hacer grupos de k bits para formar un smbolo M-ario. Es decir, la agrupacin de k bits da lugar a un smbolo de amplitud M-aria. En el caso binario, para formar un smbolo necesitamos 1 bit, pues 2=21; en el caso cuaternario, para formar un smbolo necesitamos 2 bits, pues 4=22; en el caso 8-ario, para formar un smbolo necesitamos 2 bits, pues 8=23; finalmente, en el caso 16-ario, necesitamos 4 bits, pues 16=24. Esto ya lo vimos cuando present las tablas para los sistemas 2-PAM, 4-PAM, 8-PAM y 16-PAM, siendo ste un buen momento para echarles un vistazo de nuevo y recordarlas. As, el cdigo trata de formar grupos de 1, 2, 3 4 bits, segn sea el sistema 2PAM, 4-PAM, 8-PAM 16-PAM, desde el inicio de la trama Ethernet (tramaIEEE) hasta el final de la misma. Esto lo conseguimos con el bucle
85
while i<=length(tramaIEEE) c(j)=Gray_Code(bin2dec(tramaIEEE(i:i+k))); j=j+1; i=i+k+1; end
donde k es el nmero de bits necesarios para formar un smbolo M-ario, es decir, k=log2M= 1, 2 ,3 4. La correspondencia entre bits y smbolos no es binaria natural sino Gray, por lo que es necesario la creacin de la funcin Gray_Code. La codificacin en Matlab de la misma puede hacerse de muy diversas formas, siendo, a mi entender, la creacin de una LOOKUP TABLE la ms intuitiva. Qu es una Look-Up Table o, ms coloquialmente conocida, LUT? Una LUT es una tabla que cambia su salida en funcin de la entrada que tenga, es decir, modifica dicha entrada segn su valor. Por ejemplo, en Tratamiento Digital de Imgenes, se puede usar una LUT para realizar transformaciones en los niveles de gris de una imagen a intervalos: los pixels con un determinado nivel de gris cambiaran su rango en la escala de grises. En definitiva, una Look-Up Table permite hacer transformaciones en funcin del nivel de sus entradas. Hay otras muchas aplicaciones de una LUT pero sta es la que ms nos importa ahora.
Observmos el cdigo:
function[y]=Gray_Code(x) %LOOK-UP TABLE: DECIMAL-------->CDIGO GRAY: if x==2 y=3; elseif x==3 y=2; elseif x==4 y=7; elseif x==5 y=6; elseif x==6 y=4; elseif x==7 y=5; elseif x==8
86

y=15; elseif x==9 y=14; elseif x==10 y=12; elseif x==11 y=13; elseif x==12 y=8; elseif x==13 y=9; elseif x==14 y=11; elseif x==15 y=10; else y=x; end
Es totalmente vlido tanto para el sistema 8-PAM como para el sistema 16-PAM, as como para M=2 y M=4. Su funcin es hacer la correspondencia entre bits y smbolos con codificacin Gray o, lo que es lo mismo, genera las tablas que vimos en el punto 3.2.3 Modulacin empleada de la memoria.
Ejemplo: Supongamos que el sistema es 8-PAM. Esto significa que, como 8=23, para formar un smbolo necesitaremos hacer agrupaciones de 3 bits. Consideremos que los 3 bits que han llegado a nuestro modulador son 011. Si la correspondencia entre bits y smbolos fuese binaria natural, diramos que el nivel de este smbolo sera 3. Sin embargo esto no es as pues la correspondencia es Gray; por lo tanto, 011 no es 3 en Gray, sino 2, por lo que el nivel sera 2. Esto es, precisamente, lo que hace el cdigo anterior: entramos con un valor decimal de 3 y, pasando a cdigo Gray, nos devuelve el valor de 2. Es decir, el nivel Gray para 011 es 2.
Una vez aclarada la codificacin Gray presente, nos queda por explicar un pequeo detalle dentro del bloque del modulador. Si los niveles fueran los que tenemos ahora, el rango sera 0 1 (sistema binario), desde 0 hasta 3 (sistema 4-PAM), desde 0 hasta 7 (sistema 8-PAM) o desde 0 hasta 15 (sistema 16-PAM). Esto no es errneo pero es necesario adaptar los diferentes niveles de amplitud al rango normalizado [1,...,1], como vimos en las tablas, para adecuarlo al rango que permite transmitir la tarjeta de sonido. Esto se consigue con las lneas de cdigo:
87

c=(c-0.5)/0.5; %2-PAM
c=(c-1.5)/1.5;
%4-PAM
c=(c-3.5)/3.5;
%8-PAM
c=(c-7.5)/7.5;
%16-PAM
Por ejemplo, para el nivel Gray anterior 2 en un sistema de 8 niveles (0,...,7), el valor normalizado de amplitud que le corresponde es c=(2-3.5)/3.5=-0.4285, que es el valor que aparece en las tablas. En conclusin, este bloque modulador de amplitud agrupa bits de k en k, forma smbolos utilizando la codificacin Gray y, finalmente, le dota de un carcter normalizado entre 1 y 1, que es el rango adecuado para trabajar en Matlab, segn todas las funciones relacionadas con temas de sonido y manipulacin de ficheros .WAV.
3.3.1.2.3 Transmisor
ste es el ltimo bloque de la cadena de transmisin. Aqu los datos se procesan para acomodarlos, segn nuestras necesidades, al canal digital de comunicaciones (cable de audio). Es decir, dotaremos a los datos de la codificacin de lnea Manchester con un nmero determinado de muestras por smbolo. El cdigo que he implementado para llevar a cabo el transmisor es el siguiente:
function[y]=Transmisor(c,x) %Bloque de transmisin: implementa la codificacin Manchester %de la trama modulada con M niveles de amplitud %Realiza el montado de smbolos con N=2x muestras por smbolo (x/2+x/2) j=1; i=1; while(i<=length(c)) t(j:j+2*x-1)=c(i)*[ones(1,x),-ones(1,x)]; %manchester j=j+2*x;
88

%t(j:j+x-1)=c(i)*ones(1,x); %j=j+x; i=i+1; end y=t;

%binario natural
Este funcin tiene dos parmetros de entrada:
c: es la trama IEEE (Ethernet) con niveles de amplitud en el rango normalizado [1,1]. Es, precisamente, lo que nos da el modulador: una trama normalizada con M niveles.
x: es la mitad del nmero de muestras por smbolo. 2x es el nmero total de muestras por smbolo (N): x para el nivel alto y x para el nivel bajo, dado que la llamada a esta funcin se realizaba as:
y=[y,Transmisor(trama8,N/2),zeros(1,30),1,zeros(1,50)];
es decir, con N/2 en vez de con N muestras por smbolo.
El cdigo trata de recorrer la trama modulada y normalizada desde el principio hasta el final y, por cada smbolo normalizado, genera N=2x muestras. stas estn distribuidas en dos tramos de x muestras, de acuerdo a la codificacin Manchester. Observmoslo:
while(i<=length(c)) t(j:j+2*x-1)=c(i)*[ones(1,x),-ones(1,x)]; %manchester j=j+2*x; %t(j:j+x-1)=c(i)*ones(1,x); %binario natural %j=j+x; i=i+1; end
Con el ndice i, voy recorriendo la trama inicial modulada y normalizada, incrementado 1 cada vez que se termina el bucle. Con el ndice j, voy formando la nueva trama con codificacin Manchester y N=2x muestras por smbolo. Por lo tanto, en este caso, los incrementos han de ser de 2x, para pasar convenientemente a la formacin del siguiente smbolo de 2x muestras. El resultado que devuelve la funcin Transmisor en el parmetro de salida y es lo que hay que transmitir por el cable de audio, es decir, transmitiremos tramas que cumplen todas las caractersticas que hemos desarrollado en el estudio terico. Para una mayor claridad y rapidez en los procesamientos de Matlab, el procedimiento que utilizar ser:
89
Completar la formacin de todas las tramas correspondientes al fichero que deseamos transmitir
Unirlas consecutivamente, unas detrs de otras, comenzando por las primeras y terminando por las ltimas
Realizar la transmisin propiamente dicha del conjunto anterior que, esquemticamente, podemos representarlo de la siguiente manera para hacernos una idea:
T1
T2
T3
T4
T5
T6
TX
Transmitiremos cada fichero agrupando X tramas de una longitud determinada. La ltima trama puede tener menor longitud que las dems, pues en general ocurrir que siempre quede algo del fichero que no ocupe toda la trama anterior y que habr que introducir en una nueva trama, a pesar de que el campo de datos no est ocupado en su totalidad. Las rdenes necesarias para realizar la transmisin propiamente dicha estn situadas en la parte final del programa principal (main):
dat=transmitefichero(M,N,BDT,fichero); disp('PULSE CUALQUIER TECLA PARA TRANSMITIR EL FICHERO'); pause; playsnd_nt(dat',FSAM,NB); disp('-----------------FICHERO TRANSMITIDO------------------'); disp('------------------------------------------------------');
La funcin playsnd_nt.dll (fichero ejecutable de Matlab con extensin de librera dinmica) es la encargada de transmitir, a travs del cable de audio, los datos que devuelve transmitefichero.
90
3.3.2 Cadena receptora.
3.3.2.1 Programa principal

El hilo principal del receptor es el siguiente:
function main clc disp(' ') Proyecto Fin de Carrera') disp(' disp(' ') TRANSMISIN DE DATOS MEDIANTE SOUNDBLASTER') disp(' disp(' ') disp(' ') disp('AUTOR: Juan Francisco Izquierdo Len') disp('DIRECTOR: Jos Ramn Cerquides Bueno') disp('----------------------------------------------------------------') disp('-----------------------RECEPTOR---------------------------------') disp('----------------------------------------------------------------') fichero=input('Introduzca el nombre del fichero que desea crear: ','s'); M=input('Nmero de niveles de la modulacin PAM (M=2/4/8/16): '); N=input('Nmero de muestras por smbolo (N par): '); BDT=input('Longitud (bytes) del campo de datos de las tramas Ethernet: '); FSAM=input('Frecuencia de muestreo (Hz): '); NB=input('Resolucin (8 16 bits): '); TAM=input('Longitud (bytes) del fichero: '); nmuestras=(TAM*8)*N/log2(M)+FSAM*3; %3 segundos EXTRA disp('PULSE CUALQUIER TECLA PARA COMENZAR A GRABAR...');pause; rx=recsnd_nt(nmuestras,FSAM,NB,1,0); disp('PULSE CUALQUIER TECLA PARA PROCESAR LOS DATOS REGISTRADOS...');pause; recibefichero(M,N,BDT,fichero,rx); disp('-------------------FICHERO RECIBIDO-----------------------------') disp('----------------------------------------------------------------')
91
Nuevamente, con la ayuda de la funcin input de Matlab, se solicita la entrada de datos al usuario: a. Ruta y nombre del fichero a crear b. Nmero de niveles de la modulacin M-PAM (2, 4, 8 16) c. Nmero de muestras necesarias para la codificacin de un smbolo (N par) d. Longitud en bytes del campo de datos de las tramas Ethernet que hay que formar e. Frecuencia de muestreo (Hertzios) f. Resolucin en bits de la tarjeta de sonido (8 16) g. Longitud en bytes del fichero a transmitir
Ni que decir tiene que los valores de M, N, longitud del campo de datos de las tramas, frecuencia de muestreo y resolucin deben ser exactamente los mismos que los utilizados en transmisin, con la nica excepcin de que haya que modificar, circunstancialmente, la frecuencia de muestreo para resolver problemas de falta de sincronismo en casos extremos. Seguidamente se llama a la funcin (driver .dll de sonido de Matlab) recsnd_nt, en donde registraremos los datos procedentes del cable de audio. Los argumentos son el nmero de muestras que hay que registrar (nmuestras=(TAM*8)*N/log2(M)+FSAM*3; %3 segundos EXTRA), la frecuencia de muestreo, la resolucin en bits (nmero de bits empleados para codificar el valor de una muestra), el nmero de canales de transmisin (1 canal) y el formato de presentacin de los datos registrados (precisin 0: double en la escala [-1,1]). Los 3 segundos extra son para dar tiempo al usuario para realizar la transmisin utilizando 2 PCs, de modo que cuando empiece la grabacin, dispondr de 3 segundos para comenzar la transmisin desde el otro PC. Para finalizar, se procesan los datos recibidos para crear el nuevo fichero que, si todo va bien, debe ser idntico al fichero que se transmiti. Esto se realiza mediante la siguiente llamada:
recibefichero(M,N,BDT,fichero,rx);
3.3.2.2 RecibeFichero
A continuacin vamos a ver cmo diseamos la cadena de recepcin del sistema de transmisin de datos.
92
En este bloque recibiremos y procesaremos los datos que la cadena transmisora enva a travs del cable de audio (nuestro canal de comunicaciones). En primer lugar debemos utilizar un igualador de canal o ecualizador con objeto de contrarrestar las atenuaciones que, en ciertas bandas de frecuencia, introduce el canal, as como hacer frente a los procesos dispersivos y de falta de sincronismo presentes en el sistema. Todo esto se har trama a trama, de forma que el siguiente bloque de la cadena disponga de datos ecualizados, libres de atenuacin, dispersin y falta de sincronizacin. Cuando las tramas han sido ecualizadas adecuadamente, con el igualador ZF (de cero forzado, como ya expliqu), deberemos alinearnos a ellas para extraer toda la informacin que poseen. El proceso de alineacin a la trama nos permitir conocer el contenido del campo de datos cuando realicemos la conveniente demodulacin. En cierto modo es as:
Registramos el fichero de datos transmitido que se form con la agrupacin de tramas cuyos contenidos son bloques del fichero que se deseaba enviar.
Separamos las tramas que contiene y las ecualizamos.
Realizamos la demodulacin de las mismas: o Extrayendo los datos que nos interesan o Detectando si hay errores a travs del campo del cdigo de redundancia
Reagrupamos todas los datos en un nico bloque de datos
Por ltimo, creamos el fichero recibido y, si no hay errores, ser idntico al fichero transmitido.
Todo este proceso es, sin ningn gnero de dudas, ms complicado y tedioso que el llevado a cabo en la cadena de transmisin donde, al fin y al cabo, se trata de realizar mucho procesamiento digital de la seal, adecundolo a las caractersticas del canal, de acuerdo a una modulacin y criterios de transmisin ya establecidos. Para comenzar con el cdigo, voy a presentar la rutina principal del receptor, igual que hicimos en el transmisor. En principio puede asustar un poco pero lo iremos destripando poco a poco para explicar cada uno de los procesos que tienen lugar aqu.
function RecibeFichero(M,N,BDT,fichero,rx) %BLOQUE RECEPTOR %M: modulacin M-ARIA
93
%N: nmero de muestras por smbolo %BDT: bytes de datos por trama %fichero: el que queremos transmitir %rx: datos registrados por la tarjeta de sonido disp('PROCESANDO FICHERO. POR FAVOR, ESPERE...'); i=1; while abs(rx(i))<0.3 i=i+1; end rx=rx(i-30:length(rx))'; indices=[]; k=1; while (k<length(rx)) y=find(abs(rx(k:k+14)<0.01)); if length(y)==15 while (abs(rx(k))<0.3)&(k<length(rx)) k=k+1; end indices=[indices,k-20]; k=k+100; else k=k+1; end end data=[]; n=1; inicio=indices(n); final=indices(n+1); tr=rx(inicio:final); ContadorTramas=0; ContadorErrores=0; l=BDT+1; while l>=BDT err=0; h=tr(1:50); tr=tr(51:length(tr)); x=igualadorZF(h); tr=conv(x,tr); i=1; while (abs(tr(i))<0.5)&(i<length(tr)) i=i+1; end tr=tr(i:length(tr)); i=1; tramarx=[]; while i<24*N/log2(M) simb=demodulador(tr(i:i+N-1),M,N); tramarx=[tramarx,simb]; i=i+N; end long=bin2dec(tramarx(9:24)); i=24*N/log2(M)+1; tr=tr(i:length(tr)); i=1; tramarx=[]; while i+N-1<length(tr)
94

simb=demodulador(tr(i:i+N-1),M,N); tramarx=[tramarx,simb]; i=i+N; end datos=tramarx(1:1+long*8-1); crc=tramarx(1+long*8:1+long*8+16-1); err=CalculaCrc([datos,crc],16); if ~strcmp(err,'0000000000000000') display('error(es)'); err=1; end l=long; ContadorTramas=ContadorTramas+1; if err==1 ContadorErrores=ContadorErrores+1; end data=[data,datos]; n=n+1; inicio=indices(n); final=indices(n+1); tr=rx(inicio:final); end if ContadorErrores > 0 sprintf('ERROR(ES) EN %d / %d TRAMAS ',ContadorErrores,ContadorTramas) end disp('CREANDO EL NUEVO FICHERO...'); ld=length(data); i=1; fich=[]; while i<=ld fich=[fich;bin2dec(data(i:i+7))]; i=i+8; end fid = fopen(fichero,'w'); count=fwrite(fid,fich); fclose(fid);
Esta funcin acepta los siguiente parmetros de entrada:

function RecibeFichero(M,N,BDT,fichero,rx)
M es el nmero de niveles que deseamos tener en nuestra transmisin. Por ejemplo, si la transmisin queremos que sea 8-PAM, es decir, con 8 niveles diferentes de amplitud, pasaremos el parmetro de entrada M=8.
N es el nmero de muestras por smbolo. Como usaremos el cdigo de lnea Manchester explicado con anterioridad, tendremos N/2 muestras con un nivel de los M posibles y las otras N/2 muestras con el mismo nivel pero cambiado de signo.
95
BDT es el nmero de bytes de datos que queremos transmitir en cada trama. Por ejemplo, en las tramas Ethernet IEEE 802.3, el mximo es 1500 bytes; sin embargo, ya dije que, debido a varios problemas, nuestra longitud de trama tena que ser inferior.
fichero: nombre y ruta del fichero a crear como en el pc de destino.
rx: variable que contiene todos los datos registrados por la tarjeta de sonido durante la grabacin.
Recordemos que, llegados a este punto, en rx tenemos una serie de tramas que deberemos separar convenientemente y ecualizarlas para, posteriormente, extraer los datos que, al fin y al cabo, es lo que nos interesa. Lo primero es encontrar el comienzo de todo. Para ello, buscamos la delta de Dirac que nos marca el inicio de la primera trama y, por tanto, el comienzo de todos los datos. Aqu podemos ver otra utilidad de transmitir una delta de Dirac antes de cada trama (piloto inicial): nos permite alinearnos a ella de una manera ordenada. Esto lo hacemos con el bucle:
i=1; while abs(rx(i))<0.3 %BUSCO LA DELTA DE DIRAC PREVIA A TODO i=i+1; end rx=rx(i-30:length(rx))';
mientras rx no tome un valor superior a 0.3 (la mitad del mximo), considero que no hay datos Cuando, por fin, encuentra un valor mayor que 0.3, desecho todo lo anterior y me quedo con los datos desde 30 muestras anteriores a ese pico de amplitud; la razn es sencilla: en estas 30 muestras, a pesar de tener valores inferiores a 0.3, tenemos datos que no podemos desechar: forman la cola izquierda de la respuesta a la delta de Dirac. Actualmente tenemos una seal rx formada por las tramas que se crearon en el transmisor, degradadas por el paso a travs del canal. Sigamos con el cdigo:
%VOY A RECORRER LOS DATOS RECIBIDOS PARA PODER SEPARAR LAS TRAMAS RECIBIDAS indices=[]; k=1; %recorre los datos desde el ppio hasta el final while k<length(rx) y=find(abs(rx(k:k+14)<0.01)); if length(y)==15
96

%BUSCO LA DELTA DE
while (abs(rx(k))<0.5)&(k<length(rx)) DIRAC PREVIA A LA TRAMA k=k+1; end indices=[indices,k-20]; k=k+100; else k=k+1; end end
Como dice el comentario inicial, recorremos los datos para separar las tramas. Para ello, utilizamos los impulsos presentes entre trama y trama:
He hecho un zoom entre una trama y la siguiente para ver que, efectivamente, tenemos un impulso muy til para:
Alineamiento inicial a los datos
Separacin de las tramas presentes
Ecualizacin
97
El resultado es que en la variable indices tenemos almacenadas las posiciones de comienzo de todas las tramas, que coinciden con el final de las tramas anteriores. A continuacin, inicializamos algunas variables:
inicio=indices(n); final=indices(n+1); ContadorTramas=0; ContadorErrores=0; %inicio de trama %final de trama %contador de tramas %contador de errores
y entramos en el bucle while de extraccin de tramas para completar la formacin del fichero que inicialmente transmitimos, procesando el campo de datos de las mismas. Esto lo vemos a continuacin:
3.3.2.2.1 Extraccin de tramas

Cuando hemos conseguido la alineacin a las tramas, debemos extraerlas una a una para ecualizarlas y demodularlas, con el objetivo final de recuperar los datos (procedentes del fichero transmitido) que transporta. El listado comentado es el siguiente:
err=0; %valdr 1 si hay error(es) en esta trama h=tr(1:50); %delta tr=tr(51:length(tr)); x=igualadorZF(h); %CARGO EL IGUALADOR DE CERO FORZADO (ZF) tr=conv(x,tr); %HAGO LA ECUALIZACIN i=1; while (abs(tr(i))<0.5)&(i<length(tr)) i=i+1; end tr=tr(i:length(tr)); %DETECTADO i=1; tramarx=[]; while i<24*N/log2(M) %24 bits = 3 bytes (inicio de trama(1) + londitud del campo de datos (2)) simb=demodulador(tr(i:i+N-1),M,N); tramarx=[tramarx,simb]; i=i+N; end long=bin2dec(tramarx(9:24)); %Long. del campo de datos en bytes i=24*N/log2(M)+1; tr=tr(i:length(tr)); i=1; tramarx=[]; while i+N-1<length(tr) simb=demodulador(tr(i:i+N-1),M,N); tramarx=[tramarx,simb]; i=i+N;
98

end datos=tramarx(1:1+long*8-1); crc=tramarx(1+long*8:1+long*8+16-1); err=CalculaCrc([datos,crc],16); if ~strcmp(err,'0000000000000000') %display('error(es)'); err=1; end l=long; ContadorTramas=ContadorTramas+1; if err ContadorErrores=ContadorErrores+1; end data=[data,datos]; n=n+1; inicio=indices(n); final=indices(n+1); tr=rx(inicio:final); end
Podemos observar las siguientes variables de inters:
tr: es la trama sin ecualizar que proviene de la seal rx anterior, desde el ndice inicio hasta el ndice final. Es decir, tr es una trama sin ecualizar, con el impulso inicial incluido.
M: el nmero de niveles de amplitud del sistema M-PAM.
N: es el nmero de muestras por smbolo.
M y N tienen el mismo significado que hemos visto a lo largo de toda la memoria del proyecto.
datos: es la variable ms importante ya que contiene los datos de la trama ya demodulados, listos para ser incluidos en el fichero que formaremos en el receptor, idntico al fichero transmitido.
long: es la longitud del campo de datos en bytes
err: es una variable binaria que valdr 1 si hay error(es) en esta trama y 0 en caso contrario
99
Vamos a desgranar esta funcin para ver las funciones que realiza:
1. Inicializa err a cero. 2. Extrae el impulso de Dirac transmitido al inicio de la trama:

h=tr(1:50); %delta
3. Delimita la trama propiamente dicha, excluyendo el impulso anterior:

tr=tr(51:length(tr));
4. Calcula el igualador de zero forzado y ecualiza la trama:

x=igualadorZF(h); %CARGO EL IGUALADOR DE CERO FORZADO (ZF) r=conv(x,r); %HAGO LA ECUALIZACIN
5. Detecta el comienzo de la trama ecualizada con un bucle while y delimita de nuevo el comienzo de la trama.
tr=tr(i:length(tr)); %DETECTADO
6. Recorre la trama ecualizada con un nuevo bucle while para extraer la longitud del campo de datos, demodulndolo previamente. Son 2 bytes tras el byte inicial de inicio de trama. 7. Finalmente realiza la demodulacin de los datos y del cdigo de redundancia propiamente dichos, calculando de nuevo el CRC para ver si hay o no hay errores.
NOTA: La forma de ecualizar y demodular los datos la presentar, con detalle, en los dos siguientes apartados. Hay que destacar que
La demodulacin se realiza smbolo a smbolo
En la variable tramarx tenemos almacenados todos los datos de nuestro inters: o Datos o CRC
100
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster y ambos totalmente ecualizados y demodulados.
3.3.2.2.2 Ecualizacin
La ecualizacin o igualacin de canal que vamos implementar sigue las directrices presentadas en el apartado 3.2.6 Diseo del ecualizador o igualador de canal perteneciente al bloque de 3.2 Seleccin de la tcnica de modulacin y otros parmetros de la transmisin. Recordemos que entonces desarroll toda la teora necesaria para disear un igualador de cero forzado (Igualador ZF o Zero-Forcing Ecualizer), de forma que en este momento todo estuviera claro para pasar directamente a la exposicin del listado que hace posible el diseo del ecualizador en Matlab.
ECUALIZADOR
El cdigo de la funcin igualadorZF.m es el siguiente:
%Ecualizador de cero forzado. Zero-Forcing Equalizer Design. function eq=igualadorZF(rimp) %Longitud del canal(N) lh=length(rimp); le=4*lh; %Longitud del igualador(M) c=[rimp',zeros(1,le-1)]; %Longitud=N+M-1 C=tril(toeplitz(c)); A=[]; for j=1:le A(:,j)=C(:,j); end a=lh+le-1; if mod(a,2)~=0 %N+M-1 impar b=[zeros(1,floor(a/2)),1,zeros(1,floor(a/2))]'; else %N+M-1 par b=[zeros(1,a/2-1),1,zeros(1,a/2)]'; end eq=inv(A'*A)*A'*b; %Ecualizador; long=M
Es una funcin que se llama desde RecibeFichero.m, de la siguiente forma: 101
x=igualadorZF(h); %CARGO EL IGUALADOR DE CERO FORZADO (ZF)
El objetivo es extraer un ecualizador (dinmico) ptimo para cada trama a partir del impulso de Dirac (piloto) que les precede. N es la longitud de dicho impulso y M es la longitud que deseamos que tenga el ecualizador. Una medida ptima de M se consigue como mnimo duplicando a N. Yo he elegido M=4N, ya que es ms ptimo an, si bien tambin hay que decir que hace ms lento al receptor. NOTA: Estos valores de M y N son locales y no tienen nada que ver con los vistos a lo largo de toda la memoria. El propsito del resto del cdigo es resolver el sistema matricial que ya vimos y que ahora muestro de nuevo:
h[0]
g[0]
h[1]
h[0]
g[1]
0 =
h[N-1]
h[N-2]
h[0]
h[N]
h[N-1]
h[1]
h[0]
h[N]
h[N-1]
h[N-2]
h[0]
g[M-2]
h[N]
h[N-1]
h[N-2]
h[0]
g[M-1]
donde g es el ecualizador (eq en el cdigo) y h es la respuesta impulsiva del canal que precede a cada trama (rimp en el cdigo). A partir de h hay que formar una matriz triangular inferior como la anterior. Esto lo consigo con las funciones tril y toeplitz de Matlab. Primero formo la matriz con caractersticas toeplitz y posteriormente tomo la parte triangular inferior, consiguiendo la matriz A del sistema:
102
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster A x = b
{[N+M-1]x[M]} {[M]x[1]} = {[N+M-1]x[1]} x es el ecualizador de longitud M y b es lo que pretendemos conseguir convolucionando h con g: una delta de Dirac perfecta (00000....0001000....000000) La tcnica de usar la pseudoinversa consiste, como vimos, en multiplicar por A T a ambos lados de la ecuacin y nos permite resolver el sistema:
x= A A
A b
Esto se realiza con la lnea de cdigo:

eq=inv(A'*A)*A'*b; %Ecualizador; long=M
obteniendo finalmente el igualador ZF deseado para realizar la ecualizacin.
3.3.2.2.3 Demodulacin
La demodulacin es un proceso fundamental llevado a cabo en el receptor. Trata de reconstruir los datos recibidos procedentes del transmisor. Estos tenan principalmente las siguientes caractersticas:
Modulacin PAM con M niveles posibles de amplitud para cada smbolo
Codigo Gray para la correspondencia entre bits y smbolos
Codificacin de lnea Manchester
N muestras por smbolo
Etc
El objetivo de la demodulacin es realizar todo el proceso inverso, de forma que podamos recuperar los datos procedentes del fichero que transmitimos para generarlo de nuevo en el receptor.
Fijmonos en el punto del receptor en el que estamos operando ahora: 103
Receptor Ecualizador DEMODULADOR
Es decir, hemos ecualizado la trama en cuestin y ahora pretendemos demodularla para extraer los datos de inters, smbolo a smbolo. El listado en Matlab del demodulador es el siguiente:
function[y]=demodulador(x,M,N) %N ES EL N DE MUESTRAS POR SMBOLO %Funcin base s=-[ones(1,N/2),-ones(1,N/2)]; %Salida del filtro adaptado c=conv(x,s)/(N); a=c(N); if M==2 a=round(a*0.5+0.5); %2-PAM (BINARIO) simb=mat2string(graycode(a,1)); elseif M==4 a=round(a*1.5+1.5); %4-PAM simb=mat2string(graycode(a,2)); elseif M==8 a=round(a*3.5+3.5); %8-PAM simb=mat2string(graycode(a,3)); elseif M==16 a=round(a*7.5+7.5); %16-PAM simb=mat2string(graycode(a,4)); end; %simb=dec2bin(a,4) %Smbolo binario y=simb;
Esta funcin tiene tres argumentos de entrada y uno de salida:
Parmetros de entrada: o x: seal procedente de la trama, formada por N muestras, es decir, se trata de un smbolo an sin demodular. o M: el nmero de niveles de amplitud del sistema M-PAM. o N: es el nmero de muestras por smbolo.
104
Parmetros de salida: o y: es el smbolo demodulado.
Con la realizacin de un filtrado adaptado y un muestreo posterior (anterior al bloque de decisin) deberemos conseguir realizar un demodulador bastante potente:
x(t) s: FILTRO ADAPTADO
c(t)
y(t)
Bloque de decisin
simb
t=Ts
Dado que todos los smbolos estn codificados con el cdigo de lnea Manchester, un filtro ptimo adaptado a los datos consiste en un nuevo smbolo de amplitud mxima
s=-[ones(1,N/2),-ones(1,N/2)];
que sera la funcin base nica de nuestro sistema, con esta forma:
Ejemplo: N=8 A=1 t
0 -A=-1
T/2
con N /2 (4 para nuestro ejemplo) muestras a ambos lados de T/2. La filosofa de un filtro adaptado es sta: s(t)=x*(T-t), donde d representara a los datos; por esto se conoce como filtrado adaptado (a los datos que tiene a su entrada). Como todos los smbolos en nuestro sistema tienen la misma forma, variando tan solo la amplitud (M niveles posibles), cuando filtremos y muestreemos en el punto mximo (N), la decisin posterior se tomar en base al nivel de amplitud extrado:
105
%Salida del filtro adaptado c=conv(x,s)/(N); %filtrado adaptado y normalizado a=c(N); %contiene el valor de la amplitud de x (muestreo en el mximo)
Cuando muestreamos, ya tenemos un nivel de amplitud, pero hay que hacer varias consideraciones. Este nivel de amplitud a est normalizado entre 1 y 1, como ya vimos, por lo que deberemos desnormalizarlo. o La desnormalizacin se realiza multiplicando a a por M/2 y sumando M/2 posteriormente. De esta forma, el nivel de amplitud muestreado pasa de nuevo al rango de M niveles de amplitud M/2...M/2.
Con la funcin de Matlab round tomo la decisin del smbolo Gray transmitido por redondeo en amplitud. Pero recordemos que debemos deshacer lo que hicimos en el transmisor (all hicimos corresponder bits con smbolos mediante la codificacin Gray). Esto se consigue con la funcin graycode que, a continuacin, presento:
function y = graycode(i,L) x=binarycode(i,L); y(1)=x(1); for j=2:L; if x(j-1)==1 y(j)=1-x(j); else y(j)=x(j); end end
donde se realiza una llamada a:
function y = binarycode(i,L) x=[]; q=i; while q > 0 R=q-2*floor(q/2); q=floor(q/2); x=[R x]; end n=length(x); if n==L y=x; else y=[zeros(1,L-n) x]; end
106
En ambas funciones, L es la longitud de la cadena que queremos mostrar: Si M=2, L=log2M=1 bits. Si M=4, L=log2M=2 bits. Si M=8, L=log2M=3 bits. Si M=16, L=log2M=4 bits.
Voy a explicar esto con un ejemplo hecho en Matlab: graycode(2,3)
ans =
Esta funcin llama internamente a la funcin binarycode: binarycode(2,3)
ans =
es decir, obtiene el valor en binario de 2 (010) con 3 bits y posteriormente realiza los movimientos adecuados de los bits para deshacer el cdigo Gray. Esto lo hago con un bucle for y un bucle if anidados, aunque se podra haber hecho tambin con una LUT, como ya expliqu. He elegido esta forma para poder apreciar que el uso de una LUT no es imprescindible, sino que hay siempre ms de una alternativa.
107
Lo ms importante aqu es darse cuenta de que el cdigo Gray de un nmero que supuestamente viene codificado en Gray es, precisamente, el cdigo binario natural buscado. Finalmente convierto la fila binaria en una cadena binaria de caracteres, de acuerdo a cmo lo hacamos en el transmisor, con mat2string, y se pasa como parmetro de salida. Ejemplo: 0 1 0 se convierte en 010 y es el smbolo buscado que devolvemos con la funcin demodulador.
Antes de continuar, recapitulemos los pasos ms importantes realizados en la cadena receptora. Recibimos datos estructurados en tramas. Entre una trama y otra introduzco un impulso (delta de Dirac), cuyas funciones principales son: o Alineamiento inicial al bloque de datos recibidos o Separacin de tramas, previo alineamiento a ellas o Actualizar el ecualizador trama a trama con el objetivo de:
Individualizar la igualacin de canal para cada trama
Disminuir o atenuar los efectos derivados de: La dispersin, intersimblica que dara lugar a interferencia
La falta de sincronizacin entre el transmisor y el receptor
Ecualizar la trama siguiente, tras la extraccin del ecualizador ptimo a partir del impulso intermedio. Este ecualizador es el ecualizador ZF o de cero fozado. Extraer los datos de las tramas de acuerdo a las caractersticas de transmisin fijadas. Esto se realiza en el demodulador. Finalmente, agrupar los datos extrados del campo de datos de todas las tramas que conforman el fichero transmitido para formar el nuevo fichero en recepcin. Este nuevo fichero debe ser el mismo que se transmiti. Precisamente es esto lo que a voy a detallar seguidamente.
108
Fijmonos en la parte final del archivo Matlab RecibeFichero.m:
data=[]; n=1; inicio=indices(n); final=indices(n+1); ContadorTramas=0; ContadorErrores=0; l=BDT+1; while l>=BDT [.........................] l=long; [.........................] data=[data,d]; n=n+1; inicio=indices(n); final=indices(n+1); end
l indica la longitud en bytes del campo de datos que ha extrado. Como esta operacin de extraccin debe hacerla para todas las tramas, el final lo detecta cuando una trama (su campo de datos) tiene una longitud en bytes menor que BDT, que es el tamao estndar para el campo de datos.
Ejemplo: supongamos un fichero de un tamao igual a 945 bytes. Si las tramas que formamos pueden albergar en su campo de datos hasta 100 bytes, podremos formar 9 tramas con 100 bytes de datos, que es el mximo, pero tambin nos quedar una trama que ocupar slo 45 de los 100 bytes; en este caso, deducimos que esta trama es la ltima.En el caso de que todas la ltima trama sea de la misma longitud que las dems, no hay ningn problema pues la separacin previa de tramas nos indicar que no hay ms tramas que extraer (variable indices).
Es por esta razn por la que el bucle final empieza as:

while l>=BDT
En el bucle llevamos a cabo la extraccin de los datos de las tramas:
datos es el bloque de datos extrados de una trama, ya demodulados convenientemente. 109
l es la longitud en bytes del bloque anterior.
err es una variable binaria (0/1) que indica lo siguiente: o err=0: no hubo errores en la transmisin o, al menos, eso es lo que se deduce del campo CRC-16, que es bastante fiable:
CRC-16 (DATOS+CRC-16) = 0000 0000 0000 0000 0000
o err=1: hubo error(es) en la transmisin de esa trama, ya que su demodulacin indica que el CRC-16 de la agrupacin recibida DATOS+CRC-16 no es cero (0000 0000 0000 0000).
CRC-16 (DATOS+CRC-16) 0000 0000 0000 0000 0000
A continuacin se actualizan convenientemente las variables ContadorTramas y ContadorErrores:

ContadorTramas=ContadorTramas+1; if err==1 ContadorErrores=ContadorErrores+1; end
se aaden los datos a la variable que los agrupa:

data=[data,datos];
y se preparan los delimitadores para la siguiente trama:

n=n+1; inicio=indices(n); final=indices(n+1);
Todo esto se hace para la totalidad de las tramas presentes en el bloque recibido. Antes de formar el fichero en recepcin, se muestra un mensaje informativo, si hubo errores, de las tramas errneas sobre el total:
if ContadorErrores > 0 sprintf('ERROR(ES) EN %d / %d TRAMAS ',ContadorErrores,ContadorTramas) end
110
3.3.2.2.4 Formacin del fichero

sta es la parte final y no por eso menos importante del proyecto. Se trata de formar el fichero que transmitimos en su momento a partir de la agrupacin de todos los datos recibidos con cada una de las tramas. Realmente se trata de una aplicacin que, por su escaso ancho de banda, est muy limitada en cuanto al tamao de los ficheros. Si la longitud del fichero es mucho mayor que unos cuantos Kbytes, puede ser bastante frustrante en cuanto a lentitud. Por lo tanto, est pensado para pequeas transmisiones como, por ejemplo, textos pequeos y, en general, ficheros de pequea longitud.
El listado Matlab es el siguiente:

disp('CREANDO EL NUEVO FICHERO...'); ld=length(data); i=1; fich=[]; while i<=ld fich=[fich;bin2dec(data(i:i+7))]; i=i+8; end fid = fopen(fichero,'w'); count=fwrite(fid,fich); fclose(fid);
I. Calculo la longitud de los datos que van a formar el fichero. Evidentemente, si todo ha ido bien, debe ser la misma que la longitud del fichero transmitido. II. Inicializo i=1 para recorrer los datos, que formarn el fichero fich. III. Mientras me queden datos (while i<=ld), los aadir a fich de la misma forma que los extraje en transmisin:
Agrupando los bits en grupos de ocho, es decir, en bytes
Haciendo la conversin de binario a decimal, de la forma contraria a la que se llev a cabo en transmisin (de decimal a binario)
En forma de columna
IV. Cuando ya tenemos fich completo, debemos crear el fichero propiamente dicho:
Obtengo el identificador de fichero abriendo uno nuevo con la ayuda de fopen:
111

fid = fopen(fichero,'w');
Escribo los datos (fich) en el nuevo fichero:

count=fwrite(fid,fich);
count es el nmero de elementos escritos con xito.
Cierro el fichero
fclose(fid);
En este momento, ya tenemos en el PC de destino un nuevo fichero (reconstruido a partir de las tramas recibidas) que debe ser igual o lo ms parecido posible, si es que hubo algn error, al fichero que transmitimos.
112
3.4 Programacin en C/C++ del modulador y demodulador

ste es el ltimo bloque dentro de la memoria del proyecto antes de presentar las conclusiones. Se trata de implementar todo el cdigo desarrollado en Matlab en un lenguaje de alto nivel como es el lenguaje C. Con esto conseguiremos notables ventajas:
No ser necesario ejecutar Matlab para realizar la transmisin de ficheros (si bien es cierto que en la instalacin de nuestra aplicacin ser necesaria la inclusin de algunas libreras dinmicas de Matlab (archivos de extensin .dll)).
Obtendremos dos apliciones externas independientes de Matlab (stand-alone applications).
Mejoraremos la velocidad de proceso del sistema, al ser ejecutadas directamente bajo el sistema operativo Windows.
Portabilidad del cdigo.
Etc.
Para traducir el cdigo Matlab a cdigo C/C++ he utilizado el compilador que trae incluido el paquete Matlab.Este compilador no es ms que otro toolbox (llamado compiler), cuya funcin principal es obtener listados en lenguaje C a partir de scripts y funciones con extensin .m de Matlab. A priori, podemos pensar en la gran aportacin que nos proporciona este compilador, pero lo cierto es que tiene bastantes restricciones. Desafortunadamente, algunas de estas restricciones estn presentes en este proyecto. Esto me ha obligado a crear cdigo independiente en lenguaje C, con el compilador de C/C++Borland 5, para acceder a la tarjeta de sonido, tanto en reproduccin como en grabacin, y preparar la entrada/salida de la aplicacin. En definitiva, lo ms sencillo hubiera sido traducir el cdigo en su totalidad, pero no ha podido ser as, de manera que:
La programacin de los drivers de sonido la he tenido que llevar a cabo independientemente de este compilador. Para ello, las APIs de Windows me han sido de mucha utilidad.
La entrada de datos que la aplicacin requiere para funcionar desde la lnea de comandos la he implementado tambin en C directamente, pues la funcin input de Matlab no es traducible en la versin del compilador de Matlab que yo tengo (versin 5.2).
113
Ha sido necesario reagrupar todo el cdigo para formar un nico listado, lo cual no ha sido nada fcil. Para muestra de ello basta con pensar en los tipos de datos que Matlab maneja (slo un tipo de datos y cadenas de caracteres) y compararlo con el gran abanico de tipos que existen en C (int, double, float, char, etc, etc.)
3.4.1 Cadena transmisora

Los principales pasos llevados a cabo en la cadena de transmisin son los siguientes: 1. Recogida de datos de usuario: a. Ruta y nombre del fichero a transmitir b. Nmero de niveles de la modulacin M-aria PAM (M=2, 4, 8 16) c. Nmero de muestras necesarias para la codificacin de un smbolo utilizando el cdigo de lnea Manchester (N par) d. Longitud del campo de datos de las tramas Ethernet en bytes e. Frecuencia de muestreo (Hz) f. Resolucin de la tarjeta de sonido (8 16 bits)
2. Procesamiento del fichero 3. Transmisin del fichero
La longitud del campo de datos de las tramas Ethernet y la frecuencia de muestreo son dos parmetros muy importantes para cubrir problemas de sincronismo en entornos en los que el desajuste en las frecuencias de muestreo sea importate. El procesamiento del fichero se realiza tomando como base todo el cdigo implementado en Matlab. Con el compilador de C que posee Matlab, hago la traduccin a lenguaje C. Es decir, esta parte apenas ha necesitado modificaciones, aunque alguna mejora s que he tenido que realizar. En definitiva, la adecuacin de los datos del fichero a transmitir por canal de comunicaciones sigue el proceso que inicialmente desarroll en Matlab. Por ltimo, la transmisin del fichero es lo que ms problemas me ha causado. La razn principal es que las funciones de Matlab que permiten el acceso a la tarjeta de sonido 114
en reproduccin y en grabacin no son ficheros .m propiamente dichos, sino que en el fondo son ficheros ya compilados y, por tanto, ejecutables en el entorno Matlab. Ms concretamente, se trata de ficheros con extensin de librera dinmica (.dll), que se ejecutan igual que los ficheros .m, con la peculiaridad de que el cdigo fuente no se puede ver. Qu ha significado esto? Pues que para crear una aplicacin independiente de Matlab (standalone), me ha sido necesario crear los drivers en lenguaje C, apoyndome en las APIs de Windows. Esto ha tenido pros y contras:
Las ventajas principales se basan en que todo lo referente a acceso directo a memoria (DMA), gestin de interrupciones (IRQ), lectura y escritura de registros y apertura y cierre de puertos de la tarjeta de sonido ha sido transparente para m pues forman parte de un servicio que ya proporcionan las APIs de Windows. Esto no ocurre as cuando hay que programar todo en lenguaje C para DOS.
Las desventajas o inconvenientes han sido las siguientes: a. Mi desconocimiento de la programacin en Windows a travs de las APIs, lo cual me ha obligado a aprender ciertos conceptos bsicos para manejarme con ellas medianamente bien. b. Conectar el cdigo C creado por m con el cdigo C traducido por el compilador de Matlab. Esto ha sido bastante tedioso y me ha obligado a estudiar en profundidad 3 documentos de ayuda de Matlab como son compiler.pdf, apiguide.pdf y apiref.pdf. El objetivo perseguido era la obtencind de un cdigo uniforme y homogneo que no distinguiera ambas partes. Afortunadamente, al final se consigui.
Dada la gran complejidad del tema en cuestin, he decidido presentar el cdigo tal cual, obviando ciertas cuestiones que me llevaran pginas y pginas de explicacin y que al final slo quedaran claras si el lector decidiese hacer pruebas de compilacin en la prctica. Entonces, voy a detallar cmo he realizado la compilacin del cdigo. He creado una rutina principal (main) que pide los datos al usuario, al tiempo que procesa los datos y, finalmente, realiza la tranmisin del fichero. Las funciones que permiten la transmisin estn includas en el mismo listado (playsnd_jf.c), si bien es necesario incluir las libreras windows.h y mmsystem.h. La librera matlab.h es tambin necesaria para la traduccin del cdigo, as como la librera de entrada y salida estndar stdio.h y la librera matemtica math.h. Adems, es fundamental presentar el prototipo de la funcin de matlab que va a realizar el procesamiento del fichero:
115
extern mxArray *mlfTransmitefichero(mxArray *, mxArray *, mxArray *, mxArray *); En definitiva, ha sido un duro trabajo fcilmente apreciable observando este prototipo de la funcion externa Transmitefichero de Matlab (mlfTransmitefichero):
Admite cuatro parmetros de entrada
Devuelve un parmetro de salida
siendo todos ellos del tipo puntero a array de Matlab (* mxArray). Esto es as pues en Matlab slo existe este tipo y el tipo array de Matlab (mxArray). Por esta razn, unir esto con el resto del cdigo fuente C ha sido una tarea muy complicada que he podido resolver a los documentos pdf que cit anteriormente. Por partes:
He creado el fichero principal playsnd_jf.c
Lo he compilado y linkado con el cdigo C creado por el compilador de Matlab
Todo esto para dar lugar a la rutina ejecutable TransmiteFichero.exe
Simplemente, voy a mostrar la lnea de comando necesaria para crear el ejecutable anterior a partir de playsnd_jf.c y el proyecto implementado en Matlab (transmitefichero.m):
mcc ehl transmitefichero playsnd_jf.c

Es decir, llamo al compilador de Matlab (mcc) con las opciones: e Externa. Traduce fichero .M a fichero .C para ser linkado posteriormente con la funcin de librera MATLAB C Math Library y ejecutada fuera del entorno de Matlab Cualquier llamada a subfunciones debe ser compilada dentro de la aplicacin externa resultante. Lnea. Muestra los nmeros de lnea de los ficheros de Matlab en los que pudiera haber errores de runtime.
h l
Con todo esto, el listado en C de playsnd_jf.c es el que a partir de la pgina siguiente podemos observar.
116
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster #include <stdio.h> #include <windows.h> #include <mmsystem.h> #include <math.h> #include <conio.h> #include "matlab.h"
extern mxArray *mlfTransmitefichero(mxArray *, mxArray *, mxArray *, mxArray *);
/* * Global variables. */ char szAppName[] = "tsound"; hInstApp hInst hwndApp hwndName hwndPlay hwndQuit = NULL; = NULL; = NULL; = NULL; = NULL; = NULL; = NULL; // application name // instance handle // instance handle // main window handle // filename window handle // "Play" button window handle // "Exit" button window handle
HANDLE HANDLE HWND HWND HWND HWND
HWAVEOUT
hWaveOut
LPWAVEHDR pWaveOutHdr = NULL; BOOL DWORD bClassRegistered = FALSE; dwFormat; /* hardware capabilities */
WAVEOUTCAPS wcCaps;
#define ALLOC_ERROR_MSG "Unable to allocate memory."
117
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster #define LOCK_ERROR_MSG "Unable to lock memory.";
#define DEFAULT_ERROR_MSG "Invalid sndMemError code";
typedef enum {ALLOC_ERROR, LOCK_ERROR} sndMemErrorCode;
/* NUM_MEMHANDLES: * Number of entries in the memHandles structure. There will * be two entries per buffer, to indicate if a GlobalLock was * successful. */ #define NUM_MEMHANDLES 4
void * memHandles[NUM_MEMHANDLES];
int mem_handle_count;
#define WMAIN_DX #define WMAIN_DY
207 120
typedef struct SOUNDDATA_TAG { unsigned int sFreq; // Sampling freq for data
118
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster unsigned short nChannels; unsigned int numSamples; unsigned short nBits; double *mChannelData; } SOUNDDATA; // Number of channels
// Number of samples in data // num bits requested by used // if mono, data is here
void setSndInputData(SOUNDDATA *sndData,double *data,int tam,int frequency,int n_bits) { sndData->sFreq = (unsigned int)frequency; sndData->nBits = (unsigned short)n_bits; sndData->nChannels = 1; sndData->numSamples = (unsigned int)tam; sndData->mChannelData = data; }
void setSndPlayData(SOUNDDATA *pSndPlayData, SOUNDDATA sndInputData, unsigned int nChannelsUsed, unsigned nAvailBits) { pSndPlayData->sFreq = sndInputData.sFreq; pSndPlayData->nChannels = nChannelsUsed; pSndPlayData->numSamples = sndInputData.numSamples; pSndPlayData->nBits = min(sndInputData.nBits, nAvailBits); pSndPlayData->mChannelData = sndInputData.mChannelData; 119
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster }
void setPcmWaveFormat(PCMWAVEFORMAT *pcmWaveFormat, SOUNDDATA sndPlayData, int nAvailBits) { pcmWaveFormat->wf.wFormatTag = WAVE_FORMAT_PCM; pcmWaveFormat->wf.nChannels = sndPlayData.nChannels; pcmWaveFormat->wf.nSamplesPerSec = sndPlayData.sFreq; pcmWaveFormat->wf.nAvgBytesPerSec = (LONG)(sndPlayData.nChannels * sndPlayData.sFreq * nAvailBits / 8); pcmWaveFormat->wf.nBlockAlign nAvailBits / 8); = (unsigned short)(sndPlayData.nChannels *
pcmWaveFormat->wBitsPerSample = (unsigned short)nAvailBits;
void formatData( LPSTR int pcDataBuffer, dwBestFormat,
SOUNDDATA sndPlayData ) 120
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster { short tmpValue; unsigned int i; int hwBits, preValue, scalingFactor; double quantizingFactor;
// Process the 16-case if(dwBestFormat==16) { // We have 16-bit mono data: // Need to map the data between -32768 and 32767 hwBits = 16; scalingFactor = (int)(pow(2.0, (double)(hwBits sndPlayData.nBits)));
quantizingFactor = pow(2.0, (double)(sndPlayData.nBits - 1));
for( i=0; i<sndPlayData.numSamples; i++) { // We are doing mono. If there's data in any of the // stereo channels, average the two channels to obtain // a single one. preValue = scalingFactor * (int)( sndPlayData.mChannelData[i]* quantizingFactor);
121
tmpValue = (short)min(32767, preValue);
// Don't get confused here! The resulting vector will always be // BUFFER_SIZE bytes-long. pcDataBuffer[2*i] = LOBYTE(tmpValue); // This fills up the low-byte pcDataBuffer[2*i+1]=HIBYTE(tmpValue); // This fills up the high-byte
} } // Process the 8-bit case else if(dwBestFormat==8) { // We have 8-bit mono data // Need to map it between 0 and 255 hwBits = 8; scalingFactor = (int)(pow(2.0, (double)(hwBits sndPlayData.nBits)));
quantizingFactor = pow(2.0, (double)(sndPlayData.nBits));
for(i=0; i<sndPlayData.numSamples; i++) {
122
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster // We are doing mono. If there's data in any of the // stereo channels, average the two channels to obtain // a single one. preValue = scalingFactor * (int)(
((sndPlayData.mChannelData[i]+1.)/2.)* quantizingFactor);
pcDataBuffer[i] = (unsigned char)min(255, preValue);
void sndMemCleanUp(void) { int i;
for(i=mem_handle_count-1; i>=0; i--) { if(memHandles[i]) { /* Even elements have pointers, odd elements have
123
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster * handles. */ if((i % 2)) GlobalUnlock(memHandles[i]); else GlobalFree((HGLOBAL)memHandles[i]);
memHandles[i] = NULL; } } mem_handle_count = 0; }
void sndInitMemHandler(void) { int i;
mem_handle_count = 0;
for(i=0; i<NUM_MEMHANDLES; i++) memHandles[i] = NULL;
124
void sndMemError(const sndMemErrorCode errCode) { char *errMsg;
sndMemCleanUp();
switch(errCode) { case ALLOC_ERROR: errMsg = ALLOC_ERROR_MSG; break; case LOCK_ERROR: errMsg = LOCK_ERROR_MSG; break; default: errMsg = DEFAULT_ERROR_MSG; break; }
printf("%s",errMsg); }
void * sndAllocMem(int size, DWORD dwFlags) { HGLOBAL hMem;
125
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster void *pMem;
if((hMem = GlobalAlloc( dwFlags, size))==NULL) sndMemError(ALLOC_ERROR); memHandles[mem_handle_count] = (void *)hMem; mem_handle_count++;
if((pMem = (void *)GlobalLock(hMem)) == NULL) sndMemError(LOCK_ERROR); memHandles[mem_handle_count] = pMem; mem_handle_count++;
// initialize the memory to zero memset(pMem, '\0', size);
return(pMem); } /* WndProc - Sound window procedure function. */ LONG FAR PASCAL WndProc(HWND hWnd, unsigned msg, UINT wParam, LONG lParam) { switch (msg) { case WM_DESTROY: if (hWaveOut) 126
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster { waveOutReset(hWaveOut);
waveOutUnprepareHeader(hWaveOut, pWaveOutHdr, sizeof(WAVEHDR) ); waveOutClose(hWaveOut); } break;
case MM_WOM_DONE: /* This message indicates a waveform data block has * been played and can be freed. Clean up the preparation * done previously on the header. */ waveOutUnprepareHeader( (HWAVEOUT) wParam, (LPWAVEHDR) lParam, sizeof(WAVEHDR) );
sndMemCleanUp(); /* Close the waveform output device. */ waveOutClose( (HWAVEOUT) wParam ); break; }
return DefWindowProc(hWnd,msg,wParam,lParam); } void CleanWindow(void)
127
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster { DestroyWindow(hwndApp); UnregisterClass(szAppName, hInst); } void PlayData(double *data,int tamano,int freq, int nb) { int nChannelsUsed; int nAvailBits=16; int nBufferSize; LPSTR sndFormattedData; // Pointer to formatted data SOUNDDATA sndInputData; // struct containing the user // specified data // num of Channels to be used
SOUNDDATA sndPlayData; // struct containing the data // that will be played
PCMWAVEFORMAT pcmWaveFormat; MMRESULT mmResult;
// Set up the sound data structure setSndInputData(&sndInputData,data,tamano/sizeof(double),freq,nb);
nChannelsUsed = 1;
128
// Set the "playable" data structure setSndPlayData(&sndPlayData, sndInputData, nChannelsUsed, nAvailBits);
// Prepare the PCMWaveFormat struct setPcmWaveFormat(&pcmWaveFormat, sndPlayData, nAvailBits);
// Initialize memory handler sndInitMemHandler();
//Find the mount of memory needed for the buffer nBufferSize = sndPlayData.numSamples * sndPlayData.nChannels * nAvailBits / 8;
// Allocate memory for header pWaveOutHdr = (LPWAVEHDR)sndAllocMem(sizeof(WAVEHDR), GMEM_MOVEABLE | GMEM_SHARE);
// Allocate memory for buffer sndFormattedData = (LPSTR)sndAllocMem(nBufferSize,
129
GMEM_FIXED | GMEM_SHARE);
//Set the header info pWaveOutHdr->lpData = sndFormattedData; pWaveOutHdr->dwBufferLength = nBufferSize;
// format the data formatData(sndFormattedData, nb, sndPlayData);
// Open device mmResult = waveOutOpen((LPHWAVEOUT)&hWaveOut, WAVE_MAPPER, (LPWAVEFORMAT)&pcmWaveFormat, (UINT)hwndApp, 0L, CALLBACK_WINDOW | WAVE_ALLOWSYNC ); //printf("%d\n",mmResult); if(mmResult) { sndMemCleanUp(); printf("Unable to open sound device.\n"); }
// Now we need to prepare the output device if((mmResult = waveOutPrepareHeader(hWaveOut,
130
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster pWaveOutHdr, sizeof(WAVEHDR) )) != MMSYSERR_NOERROR) { waveOutClose(hWaveOut); sndMemCleanUp(); printf("Unable to prepare header.\n"); }
if((mmResult = waveOutWrite((HWAVEOUT)hWaveOut, (LPWAVEHDR)pWaveOutHdr, (UINT)sizeof(WAVEHDR))) != MMSYSERR_NOERROR) { waveOutUnprepareHeader(hWaveOut, pWaveOutHdr, sizeof(WAVEHDR)); waveOutClose(hWaveOut); sndMemCleanUp(); printf("Unable to write into sound device\n"); }
} void main (void)
131
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster { int FSAM; int RES; double *ic;
int tamd; int k; mxArray *i; mxArray *M; mxArray *N; mxArray *BDT; mxArray *fichero; double Mc; double Nc; double BDTc; char cadena[30];
WNDCLASS
wc;
printf("\n--------------------P.F.C.------------------------------"); printf("\n-------TRANSMISION DE DATOS MEDIANTE SOUNDBLASTER-------"); printf("\n--------------------------------------------------------"); printf("\n----------AUTOR: JUAN FRANCISCO IZQUIERDO LEON----------"); printf("\n----------DIRECTOR: JOSE RAMON CERQUIDES BUENO----------"); printf("\n--------------------------------------------------------"); printf("\n------------------TRANSMISOR----------------------------");
132
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster printf("\n--------------------------------------------------------\n"); printf("\nFICHERO: "); scanf("%s",cadena); printf("M (2/4/8/16 niveles de amplitud): "); scanf("%lf",&Mc); printf("N (par): "); scanf("%lf",&Nc); printf("LONGITUD (bytes) DE LAS TRAMAS: "); scanf("%lf",&BDTc); printf("FSAM (Hz): "); scanf("%d",&FSAM); printf("RESOLUCION (8/16 bits): "); scanf("%d",&RES); printf("\n--------------------------------------------------------\n"); M = mxCreateDoubleMatrix(1,1, mxREAL); N = mxCreateDoubleMatrix(1,1, mxREAL); BDT = mxCreateDoubleMatrix(1,1, mxREAL);
mxSetData(M,&Mc); mxSetData(N,&Nc); mxSetData(BDT,&BDTc);
fichero = mxCreateString(cadena); i=mlfTransmitefichero(M,N,BDT,fichero); printf("PULSE CUALQUIER TECLA PARA TRANSMITIR EL FICHERO...");
133
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster getch(); ic=mxGetPr(i); tamd = mxGetN(i);
hInstApp = (HINSTANCE)GetWindowLong(GetFocus(), GWL_HINSTANCE); hInst = (HINSTANCE)GetWindowLong(GetFocus(), GWL_HINSTANCE);
/* Define and register a window class for the tsound window. */ wc.hCursor wc.hIcon = LoadCursor(NULL, IDC_ARROW); = LoadIcon(hInst, szAppName);
wc.lpszMenuName = szAppName; wc.lpszClassName = szAppName; wc.hbrBackground = GetStockObject(LTGRAY_BRUSH); wc.hInstance wc.style = hInst; = 0; = WndProc; = 0; = 0;
wc.lpfnWndProc wc.cbWndExtra wc.cbClsExtra
if (!bClassRegistered) { if (!RegisterClass(&wc)) { MessageBox(hwndApp, "Can't register sound window", NULL, MB_OK | MB_ICONEXCLAMATION); return;
134
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster } else bClassRegistered = TRUE; }
/* Create and show the main window. */ if (!hwndApp) hwndApp = CreateWindow (szAppName, szAppName, WS_DISABLED, // class name // caption // style bits // x position // y position // x size // y size // parent window // use class menu // instance handle // no params to pass on
CW_USEDEFAULT, CW_USEDEFAULT, WMAIN_DX, WMAIN_DY, (HWND)NULL, (HMENU)NULL, (HANDLE)hInst, (LPSTR)NULL );
atexit(CleanWindow);
135
// Make sure there's sound hardware: if(waveOutGetNumDevs() < 1) printf("No sound hardware detected.\n");
// Get hardware caps waveOutGetDevCaps(WAVE_MAPPER, &wcCaps, sizeof(WAVEOUTCAPS));
PlayData(ic,tamd*sizeof(double),FSAM,RES); printf("\n-----------------FICHERO TRANSMITIDO--------------------"); printf("\n\nPULSE CUALQUIER TECLA PARA FINALIZAR..."); printf("\n--------------------------------------------------------"); getch(); }
136
3.4.2 Cadena receptora

La cadena de recepcin la he realizado de la misma forma que la cadena transmisora, siguiendo los siguientes pasos: 1. Recogida de datos de usuario: a. Ruta y nombre del fichero que se va a crear b. Nmero de niveles de la modulacin M-aria PAM (M=2, 4, 8 16) c. Nmero de muestras necesarias para la codificacin de un smbolo utilizando el cdigo de lnea Manchester (N par) d. Longitud total del fichero en bytes e. Frecuencia de muestreo (Hz) f. Resolucin de la tarjeta de sonido (8 16 bits) g. Longitud del campo de datos de las tramas Ethernet en bytes
2. Recepcin de los datos transmitidos (creados a partir del fichero que se desea transmitir) 3. Procesamiento de dichos datos 4. Creacin del nuevo fichero
Evidentemente, para que todo funcione correctamente, el nmero de niveles de la modulacin M-PAM, el nmero de muestras necesarias para la codificacin de un smbolo, la longitud (bytes) del campo de datos de las tramas Ethernet, la frecuencia de muestreo (Hz) y la resolucin de la tarjeta de sonido deben ser las mismas que las que se us en transmisin. Si esto es as, la demodulacin se realizar adecuadamente. La frecuencia de muestreo puede variarse para solucionar los conocidos problemas derivados del desajuste en las frecuencias de muestreo de transmisor y receptor en casos extremos. La entrada datos de usuario la he implementado integramente en C (dadas las restricciones que tiene la funcin input de Matlab). Adems, he recurrido de nuevo a las APIs de Windows para poner en funcionamiento la tarjeta de sonido, de modo que pudiera registrar los datos que la cadena transmisora envi. Igualmente a lo que ocurra en el punto 3.4.1, todo esto tiene las mismas ventajas e inconvenientes que all cit.
137
Nuevamente, el procesamiento de los datos registrados y la creacin del fichero se ha realizado tomando como base el cdigo de Matlab, traducindolo apropiadamente con el compilador de C. Entonces, voy a detallar cmo he realizado la compilacin del cdigo. He creado una rutina principal (main) que pide los datos al usuario, al tiempo que realiza el registro de los datos transmitidos a travs del cable de audio y, finalmente, los procesa para crear el nuevo fichero en recepcin. Las funciones que permiten la grabacin aparecen en el mismo listado (recsnd_jf.c), si bien es necesario incluir las libreras windows.h y mmsystem.h. La librera matlab.h es tambin necesaria para la traduccin del cdigo, as como la librera de entrada y salida estndar stdio.h y la librera matemtica math.h. Adems, es fundamental presentar el prototipo de la funcin de matlab que va a realizar el procesamiento del fichero: extern mxArray *mlfRecibefichero(mxArray *, mxArray *, mxArray *, mxArray *, mxArray *); Este prototipo de la funcion externa Recibefichero de Matlab (mlfRecibefichero):
Admite cinco parmetros de entrada
Devuelve un parmetros de salida
siendo todos ellos del tipo puntero a array de Matlab (mxArray *). Nuevamente, lo presento por partes:
He creado el fichero principal recsnd_jf.c
Lo he compilado y linkado con el cdigo C creado por el compilador de Matlab
Todo esto para dar lugar a la rutina ejecutable RecibeFichero.exe
La lnea de comando necesaria para crear el ejecutable anterior a partir de playsnd_jf.c y el proyecto implementado en Matlab (transmitefichero.m) tiene la misma estructura que la anterior utilizada para la funcin transmitefichero:
mcc ehl recibefichero recsnd_jf.c

Es decir, llamo al compilador de Matlab (mcc) con las opciones:
138
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster e
Externa. Traduce fichero .M a fichero .C para ser linkado posteriormente con la funcin de librera MATLAB C Math Library y ejecutada fuera del entorno de Matlab Cualquier llamada a subfunciones debe ser compilada dentro de la aplicacin externa resultante. Lnea. Muestra los nmeros de lnea de los ficheros de Matlab en los que pudiera haber errores de runtime.
h l
Con todo esto, el listado en C de recsnd_jf.c es el siguiente:
139
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster #include <stdio.h> #include <time.h> #include <windows.h> #include <mmsystem.h> #include <math.h> #include "matlab.h"
extern void mlfRecibefichero(mxArray *, mxArray *, mxArray *, mxArray *, mxArray *);
typedef struct { int nsamps; int nchans; int fs; int bits;
void
*dataBuff;
LPWAVEHDR lpwh; HWAVEIN } UserInfo; hwi;
/* * Returns TRUE if device finished before timeout occurred.
140
* Returns FALSE if timeout occurred before device finished. */ static unsigned long waitForAudio(LPWAVEHDR lpwh, const double timeout) { /* Wait for device to reset: */ time_t loopTime, startTime;
/* Poll for data to become available */ time(&startTime); loopTime = startTime; while( (difftime(loopTime, startTime) < timeout) && !(lpwh->dwFlags & WHDR_DONE)) { time(&loopTime); } return( lpwh->dwFlags & WHDR_DONE ); }
static void FreeBuffers(UserInfo *u) { if(u->lpwh != NULL) { /* Do not free u->lpwh->lpData, as it points * directly into the returned matrix data area.
141
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster * We maintain that and return it to the user. */ free(u->lpwh); } }
void Terminate(UserInfo *u) { /* NOTE: Do not call CheckError here * (recursion can result) */ if (u != NULL) { if (u->hwi != NULL) { waveInReset(u->hwi);
if (u->lpwh != NULL) { /* Wait up to 1 sec for device to reset: */ (void)waitForAudio(u->lpwh, (double)1.0); waveInUnprepareHeader(u->hwi, u->lpwh, sizeof(WAVEHDR)); } waveInClose(u->hwi); }
142
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster FreeBuffers(u); } }
static void CheckError(UserInfo *u, MMRESULT mmResult) { static char msg[MAXERRORLENGTH];
if(mmResult != MMSYSERR_NOERROR) { /* Get error message from device driver */ MMRESULT myMMResult MAXERRORLENGTH); = waveInGetErrorText(mmResult, msg,
Terminate(u);
if(myMMResult == MMSYSERR_NOERROR) { printf(msg); } else { printf("Unknown error occurred."); } } }
143
static void MakeBuffers(UserInfo *u) { /* Allocate WAVEHDR: */ const int bufSiz = u->nsamps * u->nchans * (u->bits / 8);
LPWAVEHDR lpwh = u->lpwh = (LPWAVEHDR)calloc(1, sizeof(WAVEHDR)); if(lpwh == NULL) { CheckError(u, MMSYSERR_NOMEM); }
/* The sample buffer points directly to the return * matrix data storage area. * * For int16 and uint8, it is exactly the right size * For double, it is always a larger storage area. */ lpwh->lpData = u->dataBuff;
/* Initialize WAVEHDR: */ lpwh->dwBufferLength = bufSiz; lpwh->dwFlags } = 0;
144
static void MakeWaveFormatEX(UserInfo *u, LPWAVEFORMATEX lpwfx) { lpwfx->wFormatTag lpwfx->nChannels = WAVE_FORMAT_PCM; = u->nchans;
lpwfx->nSamplesPerSec = u->fs; lpwfx->wBitsPerSample = u->bits; lpwfx->nBlockAlign = lpwfx->nChannels * (u->bits / 8);
lpwfx->nAvgBytesPerSec = u->fs * lpwfx->nBlockAlign; lpwfx->cbSize } = 0;
/* Function: CheckFormatSupport ================================================= * Abstract: * * Checks if the device supports the requested format. */ static void CheckFormatSupport(UserInfo *u, LPWAVEFORMATEX pwfx, UINT uDeviceID) { CheckError(u, waveInOpen(
145
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster NULL, uDeviceID, pwfx, 0, 0, /* ptr can be NULL for query /* the device identifier /* defines requested format /* no callback /* no instance data */ */ */ */ */
WAVE_FORMAT_QUERY)); /* query only, do not open device */ }
static void assignUserInfoDefaults(UserInfo *u) { u->nsamps = -1; u->nchans = -1; u->fs = -1;
u->bits = -1;
u->dataBuff = NULL; u->lpwh u->hwi } = NULL; = NULL;
/*
146
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster * parseInputs * * Check input arguments and copy into data structure * Create output matrix */
UserInfo parseInputs(int nsamp,int freq,int nbit,int nchan,int preci) { double *dat; UserInfo u; int id;
assignUserInfoDefaults(&u);
u.nsamps = nsamp ; if (u.nsamps<0) { printf("Invalid number of samples."); }
u.fs = freq; if (u.fs<=0) { printf("Invalid sample rate."); }
u.bits = nbit;
147
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster if ((u.bits!=8) && (u.bits!=16)) { printf("Number of bits must be 8 or 16."); }
u.nchans = nchan; if ((u.nchans<1) || (u.nchans>2)) { printf("Invalid number of channels."); } id = preci; if (id!=0) { printf("Precision must be 0=double."); }
//u.dataBuff = (void *)dat; //u.dataBuff = (double *)dat ; dat = (double *) calloc(u.nsamps, sizeof(double)); u.dataBuff = (void *)dat;
return(u); }
double *recdata(int nmuestras, int frequency, int nbits, int ncanales,int precision)
148
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster { //MMRESULT mmResult; //MMRESULT myMMResult; //static char msg[MAXERRORLENGTH];
double *y; int i; UINT numInputDevices = waveInGetNumDevs(); UINT uDeviceID = WAVE_MAPPER;
UserInfo u = parseInputs(nmuestras,frequency,nbits,ncanales,precision); const int bufsiz = u.nsamps * u.nchans;;
if (numInputDevices == 0) { printf("No audio input devices."); return (NULL); }
/* Setup WAVE hardware and headers: */ { WAVEFORMATEX wfx; MakeWaveFormatEX(&u, &wfx);
149
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster CheckFormatSupport(&u, &wfx, uDeviceID);
MakeBuffers(&u); /* Allocate sample buffers */
CheckError(&u, waveInOpen(&(u.hwi), uDeviceID, &wfx, (DWORD)NULL, (DWORD)NULL, CALLBACK_NULL)); }
CheckError(&u, waveInPrepareHeader(u.hwi, u.lpwh, sizeof(WAVEHDR))); CheckError(&u, waveInAddBuffer( CheckError(&u, waveInStart( //mmResult=waveInAddBuffer( u.hwi, u.lpwh, sizeof(WAVEHDR)));
u.hwi)); u.hwi, u.lpwh, sizeof(WAVEHDR));
// myMMResult = waveInGetErrorText(mmResult, msg, MAXERRORLENGTH); //printf(msg); /* Wait for audio to become available: */ if (waitForAudio(u.lpwh, 2.0 + (double)u.nsamps / u.fs) == 0) { Terminate(&u); printf("Audio device failed to respond before timeout occurred."); }
#if 0
150
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster /* This should never be needed * Zero pad buffer if not completely filled */ memset(u.lpwh->lpData + u.lpwh->dwBytesRecorded, 0,
u.lpwh->dwBufferLength - u.lpwh->dwBytesRecorded); #endif
y = (double *)u.dataBuff + bufsiz-1; switch(u.bits) { case 8: { unsigned char *data = (unsigned char *)u.lpwh->lpData + bufsiz-1; for(i=0; i < bufsiz; i++) { *y-- = (*data-- - 128.0) / 128.0; } } break;
case 16: { short *data = (short *)u.lpwh->lpData + bufsiz-1;
151
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster for(i=0; i < bufsiz; i++) { *y-- = *data-- / 32768.0; } } break; }
Terminate(&u); return(y); } void main (void) {
int nm; int logbase2M; double *datos; double Mc; double Nc; double BDTc; double longtotal;
152
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster int FSAM; int RES; int ncan=1; int prec=0; //double
char cadena[30]; int tiempo; mxArray *i,*j; mxArray *M; mxArray *N; mxArray *BDT; mxArray *fichero; printf("\n--------------------P.F.C.------------------------------"); printf("\n-------TRANSMISION DE DATOS MEDIANTE SOUNDBLASTER-------"); printf("\n--------------------------------------------------------"); printf("\n----------AUTOR: JUAN FRANCISCO IZQUIERDO LEON----------"); printf("\n----------DIRECTOR: JOSE RAMON CERQUIDES BUENO----------"); printf("\n--------------------------------------------------------"); printf("\n-------------------RECEPTOR-----------------------------"); printf("\n--------------------------------------------------------\n"); printf("\nFICHERO: "); scanf("%s",cadena); printf("M (2/4/8/16 niveles de amplitud): "); scanf("%lf",&Mc);
153
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster printf("N (par): "); scanf("%lf",&Nc); printf("LONGITUD (bytes) DE LAS TRAMAS: "); scanf("%lf",&BDTc); //printf("Tiempo (seg) de grab.: "); //scanf("%d",&tiempo); printf("FSAM (Hz): "); scanf("%d",&FSAM); printf("RESOLUCION (8/16 bits): "); scanf("%d",&RES); printf("LONGITUD (bytes) DEL FICHERO: "); scanf("%lf",&longtotal); printf("\n--------------------------------------------------------\n"); if (M==2) logbase2M=1; else if (M==4) logbase2M=2; else if (M==8) logbase2M=3; else logbase2M=4;
nm=((longtotal*8)*Nc)/logbase2M+3*FSAM; M = mxCreateDoubleMatrix(1,1, mxREAL);
//3 segundos EXTRA
154
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster N = mxCreateDoubleMatrix(1,1, mxREAL); BDT = mxCreateDoubleMatrix(1,1, mxREAL); fichero = mxCreateString(cadena); i = mxCreateDoubleMatrix(1,nm,mxREAL);
mxSetData(M,&Mc); mxSetData(N,&Nc); mxSetData(BDT,&BDTc); printf("PULSE CUALQUIER TECLA PARA COMENZAR A GRABAR...\n"); getch(); datos=recdata(nm,FSAM,RES,ncan,prec);
mxSetPr(i,datos);
mlfRecibefichero(M,N,BDT,fichero,i); printf("\n-----------------FICHERO RECIBIDO-----------------------"); printf("\nPULSE CUALQUIER TECLA PARA FINALIZAR..."); printf("\n--------------------------------------------------------"); getch(); }
155
4 Manual de uso. Vista del proyecto en funcionamiento.

4.1 Vista en Matlab
4.1.1 Transmisor
Para llevar a cabo la ejecucin del proyecto en Matlab es necesario abrir Matlab y situarse en el directorio en donde se encuentre el bloque transmisor. A continuacin hay que teclear main (sin comillas) para que comience a funcionar. En este momento, el programa nos pide una serie de parmetros que deberemos introducir: a. Fichero a transmitir b. N (nmero de muestras/smbolo en codificacin Manchester) c. M (nmero de niveles de amplitud en la modulacin M-PAM empleada) d. Longitud (en bytes) de las tramas a formar e. Frecuencia de muestreo (Hz) f. Resolucin
Una muestra del funcionamiento en Matlab la podemos observar en la siguiente ventana de ejemplo, en donde se transmite una imagen ilu037.gif con:
a. 8 niveles de amplitud distintos, b. 8 bits/smbolo, c. tramas Ethernet de 100 bytes d. una frecuencia de muestreo de 44100 Hz y e. una resolucin de 16 bits
156
4.1.2 Receptor
De igual forma a cmo se realiza la transmisin en Matlab, para ejecutar la cadena receptora debemos siturarnos en el directorio en donde se encuentre instalado el bloque receptor. A continuacin hay que teclear, nuevamente, main (sin comillas) para que comience a funcionar. El programa nos pedir una serie de argumentos que deberemos introducir: g. Fichero a crear en recepcin h. N (nmero de muestras/smbolo en codificacin Manchester) i. j. M (nmero de niveles de amplitud en la modulacin M-PAM empleada) Longitud (en bytes) de las tramas a formar
k. Frecuencia de muestreo (Hz) l. Resolucin
m. Longitud (en bytes) del fichero transmitido
157
Una muestra del funcionamiento en Matlab la podemos observar en la siguiente ventana de ejemplo, en donde se recibe la imagen ilu037.gif (que antes transmitimos) con los mismos parmetros pero aadiendo la longitud total (en bytes) del fichero en cuestin:
4.2 Vista en C
4.2.1 Transmisor
Para ejecutar el proyecto realizado con lenguaje C, tan slo debemos hacer doble clic en el archivo transmitefichero.exe. A partir de aqu, el programa requiere que se introduzcan los mismos datos que los enumerados anteriormente para el transmisor de Matlab. Para ilustrar esto, realizamos la transmisin de un fichero de texto hooverphonic.txt con las siguientes caractersticas:
158
Proyecto fin de carrera Transmisin de datos mediante SoundBlaster a. 8 niveles de amplitud, b. 6 muestras/smbolo, c. tramas Ethernet de 200 bytes, d. una frecuencia de muestreo de 44100 Hz y e. una resolucin de 16 bits
4.2.2 Receptor
Para recibir ficheros buscamos, igualmente, el archivo recibefichero.exe y hacemos doble clic en l. El resultado es que deberemos introducir los datos que antes enumeramos para el receptor de Matlab, pues el programa nos los pedir secuencialmente. Por tanto, concluyendo, ejecutamos este fichero para recibir el archivo de ejemplo hooverphonic.txt (que antes transmitimos) con los mismos parmetros pero aadiendo la longitud total (en bytes) del fichero en cuestin. La ventana es la que se muestra a continuacin:
159
NOTA IMPORTANTE: En el paquete de instalacin de los programas en C/C++, se incluyen una serie de libreras de extensin dinmica (.dll) necesarias para el correcto funcionamiento de las aplicaciones. Estos ficheros .dll son ejecutables de Matlab necesarios para que el procesamiento sea correcto sin necesidad de tener instalado Matlab en el PC. Son los siguientes:
LIBMATLB.DLL LIBMAT.DLL LIBMX.DLL LIBUT.DLL LIBMCC.DLL LIBMMFILE.DLL
Adems, se incluye una versin compilada para que funcione en el caso de que el canal invierta la seal: transmitefichero_INV.exe
160
5 Conclusiones
Concluida la fase de experimentacin y elaboracin de la memoria, pasamos a la obtencin de conclusiones. Adems, en este bloque, propondr una serie de lneas futuras de trabajo as como algunas posibles propuestas de mejora. Recordemos que nuestro objetivo es transmitir datos. Estos datos son ficheros o archivos presentes en el disco duro de un PC o alguna otra unidad extrable, como el disco de 31/2, 51/4, ZIPs o CDROM. Deberemos transmitirlos hacia otro PC cercano, teniendo como nico soporte un cable de sonido (mono o estreo), terminado en dos conectores macho. Estos conectores se insertarn en las clavijas LINE-IN y LINE-OUT de las tarjetas de sonido, de forma que el conector que se inserte en la clavija LINE-OUT (tambin conocida como SPEAKER-OUT en muchas tarjetas de sonido) determinar el PC transmisor de los datos y el conector que se inserte en la clavija LINE-IN de la tarjeta de sonido presente en el otro PC determinar el PC receptor de esos datos. Los datos que contiene el fichero que vamos a transmitir los leemos byte a byte para, posteriormente, formar la cadena de bits a transmitir. Esta cadena no podemos transmitirla tal cual, dando al 0 el nivel de amplitud mnimo y al 1 es nivel de amplitud mximo, sino que hay que dotarla de un cierto formato. El formato de los datos se determina haciendo un estudio del canal digital de comunicaciones (cable de sonido) y un anlisis del nivel de ruido. El estudio del canal de comunicaciones nos proporciona informacin muy valiosa acerca de varios aspectos:
Caracterstica BP (paso de banda) del canal
Ancho de banda en torno a los 20 KHz aproximadamente
Necesidad de ecualizar la respuesta del canal pues se observa que ciertas bandas de frecuencia han sido atenuadas
Problemas de sincronismo, derivados del desajuste en las frecuencias de muestreo del transmisor y del receptor. Resolver este problema es fundamental para el resto del proyecto. Si no se resuelve esto, no hay proyecto.
El anlisis de ruido nos indica que el nivel de ste no es importante como para considerarlo a la hora de realizar el ecualizador de canal. Por tanto, las posibles alternativas derivadas del filtrado de Wiener quedan descartadas y la posibilidad de realizar un filtro igualador de cero forzado (Zero-Forcing Equalicer) toma fuerza.
161
A pesar de que el canal era paso de banda (bloquea el paso de seales con nivel de continua), la transmisin no sera paso de banda sino en banda base. Las razones eran variadas pero la ms importante es que realmente se trataba de un canal que deja pasar bajas frecuencias desde 20 Hz hasta aproximadamente 20 KHz. Para resolver el inconveniente de que el nivel de DC es bloqueado por el canal se adopt la solucin basada en una codificacin de lnea Manchester o Bifase que elimina todas las posibles componentes de continua de una seal. Posteriormente, evaluamos un problema fundamental en este sistema: el problema del sincronismo. Es consecuencia de un desajuste existente en las frecuencias del transmisor y del receptor, y supona un movimiento inesperado de muestras as como, en casos extremos, prdidas de muestras cada cierto tiempo. Esto nos facilit la labor de elegir una tcnica de modulacin adecuada pues desechamos inmediatamente todas las modulaciones clsicas paso de banda debido a que la insercin de una portadora supondra un obstculo insalvable de cara a un buen ajuste frecuencial. Propusimos varias formas de paliar este problema pero, fundamentalmente, tres son, a mi entender, las ms importantes: a. Disminuir el tamao de las tramas b. Aumentar el nmero de muestras por smbolo transmitido c. Ajustar manualmente la frecuencia de muestreo en el hipottico caso de que el desajuste de frecuencias fuera mayor que 1 Hz
La modulacin empleada en la transmisin es la modulacin M-PAM, en donde el valor de M (nmero de niveles de amplitud) queda a libre eleccin del usuario desde 2 (caso binario) hasta 16. Las tramas de datos las formamos tomando como base el estandar IEEE 802.3 (Ethernet) con algunas ligeras variaciones que ya comentamos tales como: a. Eliminacin del prembulo y del relleno b. Supresin de los campos de direccin origen y destino pues la transmisin es 1 a 1 c. Cambio del CRC-32 por el CRC-16 que es computacionalmente ms rpido y simple
La ecualizacin de los datos se lleva a cabo finalmente mediante un igualador de cero forzado que se autorrefresca trama a trama gracias a la introduccin de pilotos (impulsos unitarios) entre los distintos paquetes de informacin. Con estos pilotos resolvamos problemas de ISI y de falta de sincronismo, extrayendo siempre el ecualizador ptimo para cada trama.
162
Por ltimo, descartamos el uso de la tcnica de entrelazado de bit (interleaving) debido a que no supondra una mejora importante (pues el sistema es suficientemente bueno ya) y, adems, enlentecera considerablemente al sistema. De los bloques de programacin del modulador y del demodulador, es destacable resaltar, adems de la ardua tarea de preparacin de los ficheros de Matlab, la presencia de las APIs de Windows y notar la compleja interfaz existente entre el cdigo C creado por el compilador de C de Matlab y el lenguaje C ANSI. Observando y probando el proyecto en distintos PCs, dada la complejidad de los bloques del transmisor y, fundamentalmente, del receptor, obtengo la conclusin de que es necesario disponer de PCs medianamente potentes de cara a poder realizar una transmisin rpida en el sentido de procesamiento adicional de seal. Hay que recordar que el proyecto es un proyecto SOFTWARE en su totalidad y no disponemos de ningn dispositivo hardware que nos facilite alguna tarea. Por esta razn, deberemos tener paciencia en PCs de poca potencia en los que, por ejemplo, el clculo del CRC-16 y la extraccin del igualador ptimo trama a trama es bastante complicado desde el punto de vista de la velocidad de proceso. Recordemos que esto es un gran inconveniente con respecto a las tarjetas Ethernet, por ejemplo, en donde estas cosas implementan va hardware de la misma forma que en un MODEM para Internet. Se trata de un proyecto que, por sus conocidas limitaciones de ancho de banda, est enfocado a la transmisin de ficheros de poca extensin. Un valor ptimo estndar de la velocidad de transmisin podra estar comprendido entre los 16.5Kbps y 33Kbps. Puede alcanzarse como mximo la tasa de 88.2Kbps pero, claro, los errores son bastante importantes ya (la probabilidad de error de un sistema M-PAM con 16 niveles de amplitud y 2 muestras/smbolo en un sistema de audio como ste no es, en absoluto, despreciable teniendo en cuenta que los problemas de sincronismo hacen acto de presencia con todo su esplendor).
5.1 PROPUESTAS DE MEJORA Y LNEAS FUTURAS DE TRABAJO

Las propuestas de mejora giran, fundamentalemente, en torno a un concepto que se me antoja harto complicado. No obstante, voy a indicar de qu se trata. En este proyecto hemos realizado una transmisin basada en el registro de datos dentro una tarjeta de sonido. Hemos formado el fichero de audio a transmitir y lo hemos enviado tal cual. La propuesta que a m me gustara implementar tiene que ver con esto. El tiempo en el que estamos procesando los datos a transmitir no se est enviando nada y, por lo tanto, esto no es ptimo si se trata de un fichero de gran longitud. Podramos pensar en transmitir tramas en cuanto estuvieran formadas. Esto no es difcil pues tan slo habra que programar el driver para que transmitiera los datos trama a trama. El gran problema lo tendramos en recepcin pues tendramos que estar registrando datos constantemente, lo que supondra un desgaste abrumador para el bloque de recepcin, de forma que la velocidad de proceso sera nfima debido al colapso tan enorme de datos recibidos a travs del buffer, siendo la gran mayora
163
de ellos integrantes de los silencios que aparecen cuando el transmisor no enva nada sino que est procesando tramas. La propuesta de mejora va dirigida a la programacin de drivers de sonido en tiempo real, es decir, permitir el acceso los distintos buffers de la tarjeta de sonido receptora de modo que no hubiera que esperar a que termine la transmisin del fichero para comenzar a procesarlo en recepcin. La gran ventaja obtenida sera el ahorro de un tiempo importantsimo teniendo en cuenta el escaso ancho de banda disponible. Por lo tanto, se trata de mejorar la rapidez en el sistema permitiendo la transmisin individualizada de tramas as como su procesado en recepcin mediante el acceso a los datos que se estn registrando en la tarjeta de sonido durante dicha transmisin. Insisto en que es complicado el acceso a los buffers de recepcin en tiempo real, pero ah queda indicada esta propuesta como algo que podra incrementar la velocidad de proceso del sistema notablemente que, al fin y al cabo, es lo ms interesante en un sistema apoyado en un canal de comunicaciones cuyo ancho de banda es de escasamente 20 KHz. Podra indicar una segunda propuesta que, desde el punto de vista del conocimiento de ingeniera de telecomunicaciones, no aporta nada, pero hara ms vistoso al sistema: consistira en programar los bloques de transmisin y recepcin con alguna herramienta visual como, por ejemplo, VisualBasic VisualC (entre otros), de modo que la interfaz con el usuario fuera ms agradable con distintas ventanas, mens, colores, etc, etc. En cuanto a lneas futuras de trabajo yo resaltara sobre todo la posible ampliacin de este proyecto al funcionamiento en red. Es decir, varios PCs interconectados entre s en estrella, en anillo, todos con todos, etc, de tal manera que la transmisin de datos entre ellos se realizara tomando como base esta aplicacin de transmisin de datos mediante SoundBlaster. Considero que con un protocolo sencillo de red los resultados seran bastante interesantes, teniendo en cuenta que la nica modificacin que habra que implementar sobre este proyecto sera insertar de nuevo los campos Ethernet de direccin origen y destino en las tramas de la recomendacin IEEE 802.3. Recordemos que estos campos son descartables en una operacin de transmisin de ficheros 1 a 1, en donde no hay lugar a la confusin sobre quin enva y hacia quin se envan los datos.
Bueno, pues esto es todo. A quien pudiera interesar continuar con lo que aqu he desarrollado en la forma de Proyecto Fin de Carrera quedara encantado en colaborar aportando mis conocimientos sobre la aplicacin llevada a cabo. Muchas gracias. Juan Francisco Izquierdo Len. Direccin de correo electrnico: jfil77@yahoo.es
164

Transmisión de Datos Mediante soundBLASTER

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Transmisión de Datos Mediante soundBLASTER

Uploaded by

Copyright:

Available Formats

PROYECTO FIN DE CARRERA Ingeniera de Telecomunicacin

Transmisin de datos mediante SoundBLASTER

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

2 Estructura del proyecto

1. Anlisis y caracterizacin del canal de comunicaciones

2. Seleccin de la tcnica de modulacin y otros parmetros de la transmisin

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

3. Programacin en Matlab del modulador y demodulador

4. Programacin en C/C++ del modulador y demodulador

5. Conclusiones y posibles ampliaciones

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

3.1.1 ESQUEMA ORIENTATIVO DE UNA TARJETA DE SONIDO

LINE OUT FUERA DE LA TARJETA DENTRO DE LA TARJETA CD Audio

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

Juan Francisco Izquierdo Len

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

3.1.2 AJUSTE DE AMPLITUDES

3.1.3 RESPUESTA IMPULSIVA DEL CANAL

x[n]=[n] CABLE DE AUDIO

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

1000 1500 2000 2500 3000 3500 4000 4500 5000

Juan Francisco Izquierdo Len

Una atenuacin del nivel de seal, pues no alcanza la amplitud +1.

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

1000 1500 2000 2500 3000 3500 4000 4500 5000

Juan Francisco Izquierdo Len

3.1.4 ANLISIS DE RUIDO DEL SISTEMA

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

Densidad espectral de ruido de sistema (dB)

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster Vista lineal:

Juan Francisco Izquierdo Len

En este caso, NO aparecen armnicos en las frecuencias 50/100/150 Hz.

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

Snno(f)= |Hc(f)|2 Snni(f)

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

%Representacin del mdulo de la %respuesta frecuencial del sistema al %cuadrado

Ejecutndola, obtenemos la siguiente grfica, que representa el mdulo de Hc(f) al cuadrado:

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len

Proyecto fin de carrera Transmisin de datos mediante SoundBlaster

Juan Francisco Izquierdo Len