UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA
C ARRERA DE E SPECIALIZACIÓN EN S ISTEMAS
E MBEBIDOS

M EMORIA DEL T RABAJO F INAL

Procesador de audio digital para radios

FM

Autor:
Ing. Gastón Alfredo Vallasciani

Director:
Mg. Ing. Facundo Larosa (UTN-FRH, FIUBA)

Co-director:
Dr. Ing. Pablo Gomez (FIUBA)

Jurados:
Mg. Ing. Pablo Ridolfi (UTN-FRBA, FIUBA)
Mg. Ing. Gonzalo Sanchez (Fuerza Aérea, FIUBA)
Mg. Ing. Iván Andrés León Vásquez (FIUBA)
Este trabajo fue realizado en la Ciudad Autónoma de Buenos Aires, entre febrero
de 2019 y diciembre de 2019.
 III

Resumen

En esta memoria se presenta el desarrollo de un procesador de audio digital de

dos bandas. Este trabajo fue desarrollado para ser utilizado por radio emisoras
FM, de acuerdo con la Resolución No 142 SC/96 de la ENACOM.
Para la implementación se utilizó la plataforma EDU-CIAA-NXP junto a una
placa de circuito impreso que fue desarrollada específicamente para cumplir los
requerimientos de este trabajo. La programación fue realizada de manera
modular y se utilizaron patrones de diseño para realizar abstracción de
hardware, además de máquinas de estado para el desarrollo de los módulos de
firmware. Durante el desarrollo se realizaron tareas de diseño de alto nivel en
MATLAB y se realizó la gestión del trabajo y la documentación mediante Github.
 V

Agradecimientos

Por medio de la escritura de esta memoria concluye una etapa de aprendizaje y

crecimiento personal llevada a cabo mediante la Carrera de Especialización en
Sistemas Embebidos.
Una etapa muy linda y muy exigente que implico muchas horas de trabajo y
pocas horas de sueño. Todo este esfuerzo no fue en vano, el día de hoy tengo
la suerte de poder ejercer mi actividad profesional full time en el desarrollo de
sistemas embebidos.
Todo esto no hubiera sido posible sin el apoyo y el aporte de varias personas.
Por ello, quisiera agradecer,
Al Mg. Ing. Facundo Larosa y al Dr. Ing. Pablo Gomez por su dirección y aportes
para llevar adelante este trabajo.
A mis padres, por su guía constante y por alentarme a seguir creciendo como
profesional día a día.
A mi hermana, Francia, por ayudarme a realizar algunas imágenes de esta me-
moria.
Al diseñador industrial Alan Smirnoff por diseñar el acrílico para la presentación
de este trabajo.
A mi novia Nuria, por su apoyo constante y por tolerar mis momentos de abs-
tracción mental cuando me enfoco en un proyecto nuevo. Además, sin duda, el
diseño de mis presentaciones no sería tan satisfactorio sin su intervención.
A todos ellos, simplemente gracias.
 VII

Índice general

Resumen III

1. Introducción General 1
1.1. Procesadores de audio . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Introducción Específica 5
2.1. Descripción del equipo . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Señal de radio FM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Digitalización de una señal de audio . . . . . . . . . . . . . . . . . . 8
2.4. Patrones de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Filtros FIR aplicados a procesamiento de audio . . . . . . . . . . . . 10
2.6. Compresores de audio . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7. Tecnologías empleadas en este trabajo . . . . . . . . . . . . . . . . . 13
2.7.1. Hardware utilizado: EDU-CIAA-NXP . . . . . . . . . . . . . 13
2.7.2. Audacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7.3. MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7.4. KiCad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.8. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3. Diseño e Implementación 17
3.1. Metodología de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1. Gestión del proyecto en Github . . . . . . . . . . . . . . . . . 17
3.1.2. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Firmware de procesamiento de Audio . . . . . . . . . . . . . . . . . 20
3.2.1. Máquina de estados del procesador de audio . . . . . . . . . 20
3.2.2. Adquisición y generación de audio . . . . . . . . . . . . . . . 21
Implementación ping-pong buffer . . . . . . . . . . . . . . . . 21
Implementación del patrón de diseño . . . . . . . . . . . . . 24
3.2.3. Implementación de filtros para procesamiento de audio . . . 25
Filtro pasabajos 15 kHz . . . . . . . . . . . . . . . . . . . . . 25
Filtro crossover . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.4. Compresor de audio . . . . . . . . . . . . . . . . . . . . . . . 29
3.3. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1. Análisis de los circuitos más importantes . . . . . . . . . . . 31
3.3.2. Diseño de circuito impreso . . . . . . . . . . . . . . . . . . . 32
3.4. Interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4. Ensayos y Resultados 37
4.1. Adquisición y generación de audio . . . . . . . . . . . . . . . . . . . 37
4.2. Filtros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3. Compresor de audio . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
VIII

4.4. Ensayo integrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.5. Resumen de los resultados . . . . . . . . . . . . . . . . . . . . . . . . 44

5. Conclusiones 47
5.1. Trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Bibliografía 49
 IX

Índice de figuras

1.1. Procesador de audio digital ORBAN1 . . . . . . . . . . . . . . . . . . 2

1.2. Procesador de audio digital M312 . . . . . . . . . . . . . . . . . . . . 2
1.3. Diagrama general del equipo. . . . . . . . . . . . . . . . . . . . . . . 3

2.1. Diagrama en bloques del equipo. . . . . . . . . . . . . . . . . . . . . 6

2.2. Espectro de radiodifusión. . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Señal de FM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Digitalización de una señal analógica. . . . . . . . . . . . . . . . . . 9
2.5. Patrón de diseño utilizado. . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6. Diagrama general filtro FIR. . . . . . . . . . . . . . . . . . . . . . . . 11
2.7. Diagrama general del compresor VCA. . . . . . . . . . . . . . . . . 12
2.8. Respuesta temporal del compresor de audio. . . . . . . . . . . . . . 12
2.9. Plataforma de desarrollo EDU-CIAA-NXP3 . . . . . . . . . . . . . . . 13
2.10. Entorno de desarrollo, Audacity. . . . . . . . . . . . . . . . . . . . . 14
2.11. Entorno de desarrollo, MATLAB. . . . . . . . . . . . . . . . . . . . . 14
2.12. Entorno de desarrollo, KiCad. . . . . . . . . . . . . . . . . . . . . . . 15

3.1. Modelo de gestión de ramas utilizado. . . . . . . . . . . . . . . . . . 18

3.2. Ramas generadas durante el desarrollo del trabajo. . . . . . . . . . . 19
3.3. Wiki de github. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Máquina de estados del procesador de audio. . . . . . . . . . . . . . 20
3.5. Sistema de adquisición y generación de audio. . . . . . . . . . . . . 22
3.6. Diagrama de flujo del ping-pong buffer. . . . . . . . . . . . . . . . . . 23
3.7. Respuesta en magnitud del filtro diseñado. . . . . . . . . . . . . . . 26
3.8. Respuesta en fase del filtro diseñado. . . . . . . . . . . . . . . . . . . 26
3.9. Retardo de grupo del filtro diseñado. . . . . . . . . . . . . . . . . . . 27
3.10. Retardo de fase del filtro diseñado. . . . . . . . . . . . . . . . . . . . 27
3.11. Retardo de fase del filtro diseñado. . . . . . . . . . . . . . . . . . . . 28
3.12. Respuesta en magnitud de los filtros diseñados. . . . . . . . . . . . 29
3.13. Respuesta en fase de los filtros diseñados. . . . . . . . . . . . . . . . 29
3.14. FSM del compresor de audio. . . . . . . . . . . . . . . . . . . . . . . 30
3.15. Circuito de acondicionamiento de la señal para la adquisición de
audio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.16. Circuito de generación de audio por medio del DAC. . . . . . . . . 33
3.17. Circuito de manejo de leds para interfaz de usuario. . . . . . . . . . 33
3.18. Modelo 3D PCB desarrollado. . . . . . . . . . . . . . . . . . . . . . . 34
3.19. PCB fabricado con componentes montados. . . . . . . . . . . . . . . 35
3.20. Ubicación de los componentes de la interfaz de usuario. . . . . . . . 36

4.1. Medición de latencia mediante osciloscopio. . . . . . . . . . . . . . 38

4.2. Medición de distorsión armónica mediante analizador de espectro. 38
4.3. Banco de pruebas de filtros. . . . . . . . . . . . . . . . . . . . . . . . 39
X

4.4. Entrada comparada con salida del procesador de audio con tono
de 1 kHz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5. Entrada comparada con salida del procesador de audio con tono
de 10 kHz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.6. Entrada comparada con salida del procesador de audio con tono
de 14 kHz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.7. Entrada comparada con salida del procesador de audio con tono
de 19 kHz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.8. Tono de 5 kHz generado con Audacity para test de compresor de
audio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.9. Medición del tiempo de ataque sobre la señal procesada por el
compresor de audio. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.10. Medición del tiempo de relajación sobre la señal procesada por el
compresor de audio. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.11. Banco de pruebas del ensayo integrador. . . . . . . . . . . . . . . . . 45
4.12. Lectura del osciloscopio resultante del ensayo integrador. . . . . . . 45
 XI

Índice de Tablas

1.1. Comparación entre OPTIMOD-FM 8700i y MK3. . . . . . . . . . . . 2

4.1. Tabla de conformidad de los requerimientos. . . . . . . . . . . . . . 46

 1

Capítulo 1

Introducción General

En este capítulo se presenta una breve introducción a los procesadores de audio,

la situación mundial en cuanto a su desarrollo, y la situación nacional. Por último,
se expresa la motivación para desarrollar este proyecto y los objetivos y alcance
del mismo.

1.1. Procesadores de audio

Un procesador de audio es un equipo que modifica los parámetros de una señal

de audio, tales como su rango dinámico y su relación señal a ruido. Además,
permite filtrar el contenido armónico indeseado y ecualizar las distintas bandas
de frecuencia según sea requerido por el operador.
El procesamiento de audio puede ser realizado de forma digital o analógica. Si
bien ambas posibilidades se encuentran disponibles en el mercado y brindan un
procesamiento adecuado, el procesamiento digital tiene como ventaja la reduc-
ción sustancial de componentes. Esto produce una reducción en los costos con
respecto a procesadores analógicos. También permite realizar actualizaciones so-
bre el equipo con mayor facilidad y simplificar en gran medida la calibración en
fábrica y la puesta en marcha del equipo.
Este trabajo se encuentra enfocado principalmente en procesadores de audio apli-
cados a radiodifusión ya que se pretende que, una vez logrado el funcionamiento
deseado, se comercialice en ese rubro.
Los procesadores de audio para FM (Frecuencia Modulada), toman la señal de
audio proveniente de una consola presente en un estudio de radio, la procesan
y entregan la señal procesada al transmisor de FM. El transmisor de FM toma
la señal de audio procesada y la transmite en la banda de FM que se encuentra
comprendida en el rango de 89,7 MHz a 108 MHz.
Actualmente, a nivel internacional existen grandes fabricantes de procesadores
de audio tales como ORBAN u OMNIA. En la figura 1.1 se presenta un procesa-
dor de audio digital ORBAN modelo OPTIMOD-FM 8700i.
En Argentina, uno de los principales fabricantes de procesadores de audio y
transmisores para FM es la empresa M31 electrónica S.R.L. Esta empresa fabri-
ca procesadores de audio basados principalmente en circuitos combinacionales y
2 Capítulo 1. Introducción General

F IGURA 1.1: Procesador de audio digital ORBAN1 .

tecnología analógica. En la figura 1.2 se presenta el procesador de audio digital

modelo MK3 fabricado por M31 Electrónica.

F IGURA 1.2: Procesador de audio digital M312 .

En la tabla 1.1 se presenta una comparación entre el procesador ORBAN modelo

OPTIMOD-FM 8700i y el procesador de M31 Electrónica modelo MK3.

TABLA 1.1: Tabla comparativa entre OPTIMOD-FM 8700i y MK3

Fabricante ORBAN M31 Electrónica

Modelo OPTIMOD-FM 8700i MK3
Tecnología DSP Analógica
Entrada de audio Analógica y digital Analógica
Frecuencia de muestreo 32, 44,1, 48, 88,2 y 96 kHz No
Latencia Entre 3.7 ms y 20 ms según ajustes No
Salida de audio Analógica y digital Analoǵica
Número de bandas 5 bandas y 2 bandas 3 bandas
Streaming Sí No
Control remoto por TCP/IP Sí No
Indicaciones para operador Display Indicadores led
Puesta en marcha Simple Compleja

Si se analiza la tabla 1.1, resulta interesante ver la frecuencia de muestreo y la

cantidad de bandas sobre las cuales realiza el procesamiento cada equipo. La fre-
cuencia de muestreo mientras más alta sea menos ruido introducirá en la digitali-
zación de la señal de audio. El procesador MK3 no posee frecuencia de muestreo

1
https://www.orban.com/optimodfm-8700i
2
http://m31electronica.com/
1.2. Motivación 3

ya que es un dispositivo basado en tecnología analógica. El número de bandas

sobre la cual se procesa la señal permite sectorizar el procesamiento según cada
banda y por lo tanto mejorar la calidad de audio según la cantidad de bandas
sobre las cuales trabaja el dispositivo.
El equipo desarrollado en este trabajo posee una frecuencia de muestreo de 44,1
kHz y realiza el procesamiento de audio sobre 2 bandas.
Un diagrama general del trabajo se presenta en la figura 1.3. El procesador de au-
dio digital se encuentra representado por el bloque amarillo, mientras que en los
bloques color azul se encuentra representado el ambiente con el cual interactúa el
procesador. En la entrada del procesador se encuentra la consola del estudio de
radio que entrega la señal analógica al procesador. En la salida del procesador se
encuentran encerrados en un recuadro de líneas punteadas los dos sistemas de
salida: el de radio online y el sistema transmisor de radio FM.

F IGURA 1.3: Diagrama general del equipo.

1.2. Motivación

Dada la experiencia que el autor desarrolló a lo largo de dos años en la indus-

tria de los transmisores de AM y FM como ingeniero de desarrollo de nuevos
productos en M31 electrónica S.R.L. adquirió un gran interés por las tecnologías
involucradas en la industria de la radiodifusión. En la empresa el autor trabajó en
el diseño e implementación de un equipo excitador de FM que se encargaba de
la sintonización para la transmisión de FM. Una vez logrado ese proyecto surgió
el interés por el procesador de audio. Este proyecto trata sobre el procesamiento
digital de señales con un microcontrolador, un tema de gran interés para el autor
de este documento.
4 Capítulo 1. Introducción General

En cuanto al desarrollo, resulta interesante trabajar con esta clase de equipos ya

que implica la aplicacioń de técnicas para el procesamiento de grandes volúme-
nes de datos y técnicas para la optimización de tiempos de procesamiento.

1.3. Objetivos y alcance

Teniendo en cuenta los costos de equipos de fabricantes extranjeros y la tecnolo-

gía de los procesadores fabricados actualmente en Argentina, el objetivo principal
de este proyecto es abrir las puertas al desarrollo en nuestro país de un procesa-
dor digital de fácil fabricación, puesta en marcha y bajo costo. Además, un equipo
basado en un procesador permite modularizar el desarrollo lo que agrega versa-
tilidad en la incorporación de nuevas funcionalidades sin necesidad de realizar
un rediseño total del hardware. Ésto, a su vez, reduce en gran medida los tiempos
de desarrollo.
El trabajo realizado forma parte de un proyecto más amplio que implica el desa-
rrollo de un procesador de audio digital que permita enviar la señal procesada
por medio de radiofrecuencia para radios FM o por streaming para radios online.
El alcance de este proyecto abarcó el diseño y la implementación de un primer
prototipo del procesador de audio digital con salida al transmisor de FM. El pro-
totipo implicó el desarrollo del hardware necesario para adquisición y el firmwa-
re de los principales módulos del procesador.
 5

Capítulo 2

Introducción Específica

En este capítulo se aborda la descripción teórica de las técnicas y las funcionali-

dades de procesamiento de audio implementadas, las tecnologías de hardware y
software utilizadas y los requerimientos del proyecto.

2.1. Descripción del equipo

Como se menciona en la sección 1.3, este proyecto comprende el diseño e imple-

mentación de un equipo que permite realizar el procesamiento de audio prove-
niente de un estudio de radio y enviarlo al transmisor de FM.
En la figura 2.1 se presenta un diagrama de bloques de la estructura del procesa-
dor de audio digital implementado en este trabajo. La topología del procesador
comprende una serie de bloques conectados en cascada. Esto se debe a que el
procesador ejecuta procesamientos secuenciales sobre la señal de entrada y luego
la inyecta en el transmisor de FM [3].
En la figura 2.1 se distinguen bloques de tres colores diferentes. En los bloques
de color azul se encuentran representadas las conexiones externas al procesador
de audio. Los bloques denominados “Audio canal izquierdo” y “Audio canal de-
recho” representan la señal de entrada al dispositivo, mientras que el bloque de-
nominado “Transmisor de FM” representa el equipo transmisor sobre el cual el
procesador inyecta la señal de audio procesada. El bloque verde representa el
hardware desarrollado en el procesador de audio para realizar el acondiciona-
miento de la señal para su posterior digitalización. El conjunto de bloques de
color naranja representa el procesamiento de audio realizado por firmware.
A continuación, se describe cada uno de los bloques que componen al procesador
de audio según su funcionalidad:
1. ADC (Analog to Digital Converter, Conversor Analógico Digital): Se encar-
ga de digitalizar la señal de audio a una frecuencia de 44,1 kHz con una
resolución de 10 bits.
2. Filtro de entrada: filtra la señal digitalizada para limitar el contenido espec-
tral a 15 kHz.
3. Simetrizador de picos: comprime la señal de audio con un compresor lento.
4. Filtros de bandas: efectúa la separación de la señal de entrada en dos bandas
de frecuencias.
6 Capítulo 2. Introducción Específica

F IGURA 2.1: Diagrama en bloques del equipo.

5. Compresión rápida: realiza una compresión rápida sobre ambas bandas.

6. Suma de bandas: reconstruye la señal de audio realizando la suma de ban-
das.
7. Clipper: recorta la señal de audio reconstruida cuando su amplitud supera
un nivel predefinido.
8. DAC (Digital to Analog Converter, Conversor Digital Analógico): Genera la
señal de audio analógica a partir de la señal de audio digital a una frecuen-
cia de 44,1 kHz con un resolución de 10 bits.
2.2. Señal de radio FM 7

2.2. Señal de radio FM

La banda de radio de FM se encuentra comprendida en el rango de 88 a 108

MHz. Las estaciones de FM tienen asignadas frecuencias centrales empezando
en 88,1 MHz, con una separación de 200 kHz. Estas estaciones de FM tienen una
desviación máxima de su frecuencia central de 75 kHz. De esta forma, se dejan
bandas de guarda superior e inferior de 25 kHz para minimizar la interacción con
las bandas de frecuencias adyacentes.
Debido a la división de la banda de FM para la transmisión de FM estéreo, el
límite de frecuencia para la transmisión de la música es de 15 kHz. Esto permite
la transmisión de señal de alta fidelidad. En la figura 2.2 se presenta el espectro
de radiodifusión.

F IGURA 2.2: Espectro de radiodifusión.

La frecuencia de la portadora se encuentra modulada con la señal suma de los

canales izquierdo y derecho, y por la señal diferencia de 38 kHz con portadora
suprimida. Además, se agrega en el codificador estéreo la señal piloto en 19 kHz.
Dicha señal es utilizada para la decodificación en la recepción de la señal de FM.
La señal descripta se presenta en la figura 2.3.
En Argentina, el espectro de radiofrecuencia se encuentra regulado por el Ente
Nacional de Comunicaciones, también denominado ENACOM. El equipo trans-
misor de FM debe cumplir con la Resolución No 142 SC/96 denominado Regla-
mento General del Servicio de Radiodifusión Sonora Por Modulación de Frecuen-
cia. Esta resolución establece que el contenido armónico de audio debe estar con-
tenido entre 50 Hz y 15 kHz, por ello se limitó el mismo mediante un filtro FIR
pasabajos con frecuencia de corte en 15 kHz [4].
8 Capítulo 2. Introducción Específica

F IGURA 2.3: Señal de FM.

2.3. Digitalización de una señal de audio

El equipo desarrollado en este trabajo implementa distintos filtros y comprime

señales de audio. La señal de audio es una señal sonora capturada por un trans-
ductor de presión que convierte ondas sonoras en señales analógicas.
Las principales características de este tipo de señales en el dominio temporal son:
valor pico, rango dinámico, potencia y relación señal a ruido. El rango dinámico
indica la relación entre la amplitud máxima de la señal y la amplitud mínima por
encima del nivel de ruido. La relación señal a ruido es el cociente entre la poten-
cia de la señal y la potencia de ruido. En el dominio de la frecuencia caracterizan
a este tipo de señales el ancho de banda, la frecuencia fundamental y la distor-
sión armónica. Una señal de audio posee un ancho de banda que se encuentra
comprendido en el rango audible de frecuencias de 20 a 20 kHz [12].
Los principales parámetros para la digitalización de una señal de audio analógica
son la frecuencia de muestreo y la resolución. Los valores usuales para estos dos
parámetros son para la frecuencia de muestreo 44,1 kHz en adelante, mientras
que la resolución puede tomar valores de 8 bits, 10 bits, 16 bits o 24 bits para
audio de alta calidad.
Cuando se digitaliza una señal analógica se debe tomar en cuenta el teorema de
Nyquist. Este teorema especifica que para digitalizar una señal analógica y pos-
teriormente poder reconstruirla como la señal original se debe muestrear como
mínimo con una frecuencia del doble de la frecuencia máxima de la señal que
se quiere digitalizar. Si se tiene en cuenta que la señal de audio posee un ancho
de banda de 20 kHz, la frecuencia de muestreo mínima debe ser de 44 kHz. El
proceso de digitalización de una señal analógica se presenta en la figura 2.4.
En todo sonido complejo, como el que produce un instrumento de cuerda, las
frecuencias que se generan pueden ser superiores a 20 kHz. Cuando se digitaliza
un sonido que contiene frecuencias superiores a las que puede codificar el ADC,
se produce el fenómeno llamado aliasing. Este fenómeno introduce frecuencias
nuevas que no estaban presentes en la señal original lo que aumenta la distorsión.
Otro problema inherente al sistema de digitalización se produce por el proceso
de cuantificación. Éste resulta de igualar los niveles de las muestras de amplitud
2.4. Patrones de diseño 9

F IGURA 2.4: Digitalización de una señal analógica.

continua a los niveles de cuantificación más próximos. En este caso se introducen

redondeos constantes que añaden distorsión. Esta distorsión es especialmente au-
dible y degrada la calidad del sonido de manera muy notoria. A este problema se
lo denomina error de cuantificación. Este tipo de error no se produce únicamente
durante la digitalización sino que también se produce en cualquier operación que
se realice sobre una señal de audio digital [13].
El teorema de Nyquist, el fenómeno de aliasing y el error de cuantificación fueron
tomados en cuenta durante el desarrollo de este trabajo.

2.4. Patrones de diseño

Un patrón de diseño, en ingeniería de software, es una solución general reutili-

zable que es aplicable a un problema que ocurre comúnmente durante la etapa
de diseño del software. Un patrón no se puede transformar directamente en có-
digo, sino que es una descripción o plantilla sobre cómo se puede resolver un
problema, el cual puede aplicarse en diferentes situaciones. Los patrones son una
formalización de buenas prácticas de diseño de software. Los patrones permiten
abstraer la implementación de software, lo que permite generar código reutiliza-
ble. Si bien son técnicas de programación aplicadas a software existen clases de
patrones para sistemas embebidos [6].
10 Capítulo 2. Introducción Específica

En este trabajo se implementó un patrón de diseño de hardware. La función del

patrón de diseño utilizado es crear un elemento de software responsable de ac-
ceder a un elemento de hardware y encapsular la implementación de códigos y
datos del mismo. El patrón utiliza una clase para encapsular todos los accesos
al dispositivo de hardware, independientemente de su interfaz física. Además,
el patrón publica servicios que permiten escribir y leer valores desde y hacia el
equipo, así como inicializar, configurar y cerrar el mismo. De esta forma, el pa-
trón de diseño provee una interfaz independiente de la interfaz específica del
hardware, lo cual promueve una fácil modificación en caso de que el equipo o su
implementación cambie. El patrón de diseño de hardware propone implementar
las funciones que se presentan en la figura 2.5. En ésta se puede observar que
el cliente utiliza las función pública initialize() para inicializar el módulo, confi-
gure() para configurarlo, disable() para deshabilitarlo y access() y mutate() para
intercambiar datos con las funciones privadas unmarshal() y marshal() que pro-
veen la abstracción de hardware y generan la portabilidad que provee este tipo
de patrón [7].

F IGURA 2.5: Patrón de diseño utilizado.

2.5. Filtros FIR aplicados a procesamiento de audio

En acústica, los filtros poseen una frecuencia central de ganancia constante du-
rante una octava o fracción de octava y luego comienzan a atenuar la amplitud
con una pendiente que es generalmente de 6 dB/oct, 12 dB/oct o 18 dB/oct. Al
procesar una señal de audio mediante un filtro, se introduce un desplazamien-
to de fase que puede ser interpretado como un retardo, es decir, que la salida se
encuentra retrasada en tiempo con respecto a la entrada. En general, el retardo
es diferente para las distintas frecuencias, por lo tanto, cuando se tiene una se-
ñal que se encuentra compuesta por muchas frecuencias, a la salida del filtro ésta
puede verse afectada en fase, y de esta forma llega desfasada al oyente.
Los retardos de interés son el retardo de fase y el retardo de grupo. Éstos son una
medida de la linealidad de un filtro, lo ideal es que el filtro sea de fase lineal de
forma que todas las frecuencias presenten un retardo constante [2].
2.6. Compresores de audio 11

En los procesadores de audio los filtros son utilizados para limitar el ancho de
banda de la señal de audio de entrada a 15 kHz. Además, los filtros son utiliza-
dos para implementar el filtro crossover de división de bandas y para mejorar la
relación señal a ruido a la salida del procesador.
Los filtros FIR (Finite Impulse Response, Respuesta Finita al Impulso) poseen la ca-
racterística de tener una respuesta al impulso de duración limitada en el tiempo
y su salida depende únicamente de la señal de entrada. A su vez, tienen la po-
sibilidad de tener fase lineal si su respuesta al impulso es simétrica. El hecho de
que la fase sea lineal implica que el filtro no distorsiona la señal en la banda de
paso. Ésta es la característica principal para su aplicación para el procesamiento
de audio.
En la figura 2.6 se presenta la estructura genérica de un filtro FIR. En ésta se ob-
serva que en su implementación sólo se utilizan muestras retardadas de la señal
de entrada. Además, como se puede observar, este tipo de filtros al ser realizados
de forma no recursiva son intrínsecamente estables a diferencia de los filtros IIR
(Infinite Impulse Response, Respuesta Infinita al Impulso) [8].

F IGURA 2.6: Diagrama general filtro FIR.

Para este trabajo se implementaron filtros del tipo Parks Mcclellan debido a que
este tipo de filtros minimiza el error en la banda de paso y en la banda de stop.

2.6. Compresores de audio

Los compresores de audio son utilizados para modificar el rango dinámico de

la señal de audio. En este trabajo se implementó un compresor digital tipo VCA
(Voltage Controlled Amplifier, Amplificador Controlado por Voltaje) basado en de-
tección de picos. En la figura 2.7 se presenta un diagrama simplificado del com-
presor implementado.
El compresor se compone principalmente de un detector de nivel, un control de
ganancia y un amplificador controlado por voltaje. Su funcionamiento consiste
en comparar periódicamente la señal de entrada con un valor de tensión deter-
minado, al cual se lo denomina umbral; mientras este valor no es superado, el
compresor no actúa, es decir, la ganancia del VCA siempre es igual a la unidad.
Caso contrario, cuando el valor de entrada supera el valor umbral el VCA actúa
y comprime la señal según la relación de compresión del compresor.
12 Capítulo 2. Introducción Específica

F IGURA 2.7: Diagrama general del compresor VCA.

El compresor tiene los siguientes parámetros configurables:

Umbral: como fue explicado anteriormente es el valor de tensión a partir
del cual actúa el compresor. Esta acción se denomina “gatillado”.
Relación de compresión: es una medida de cuánto comprime el compresor.
Tiempo de ataque (ta): es el tiempo que tarda en comprimir hasta el máximo
valor de salida fijado por la relación de compresión luego del gatillado.
Tiempo de relajación (tr): es el tiempo de vuelta al estado de reposo del
compresor luego de finalizado el tiempo de ataque.
Los distintos parámetros temporales permiten incorporar los cambios graduales
de la ganancia. Ésto se logra a través de una envolvente que tarda un determinado
tiempo en actuar hasta lograr la compresión fijada por la relación de compresión.
En la figura 2.8 se observa como el procesador opera de manera gradual hasta
lograr el control cuando se ingresa una señal continua con una amplitud mayor
al umbral. Igualmente sucede al retirar la compresión, se produce una descom-
presión suave y controlada [5].

F IGURA 2.8: Respuesta temporal del compresor de audio.

2.7. Tecnologías empleadas en este trabajo 13

2.7. Tecnologías empleadas en este trabajo

A continuación se presentan las herramientas de hardware y software utilizadas

durante el desarrollo de este trabajo.

2.7.1. Hardware utilizado: EDU-CIAA-NXP

Para el desarrollo del trabajo se utilizó la plataforma EDU-CIAA-NXP, una he-

rramienta diseñada como parte del proyecto CIAA con el objetivo de proveer de
una plataforma de desarrollo moderna y económica a los docentes y estudiantes
en cursos de sistemas embebidos [11].
La EDU-CIAA-NXP posee integrado el microcontrolador LPC4337. Éste es un
microcontrolador con arquitectura ARM basada en un núcleo M4 y un núcleo M0.
Esta plataforma fue utilizada durante la Carrera de Especialización en Sistemas
Embebidos. Además, posee dos ADC y un DAC con una resolución de 10 bits, y la
posibilidad de configurar su frecuencia de adquisición y generación en 44,1 kHz
respectivamente. Estas características hicieron que se la considere apropiada para
el desarrollo del trabajo. En la figura 2.9 se presenta la herramienta de desarrollo
EDU-CIAA-NXP.

F IGURA 2.9: Plataforma de desarrollo EDU-CIAA-NXP1 .

2.7.2. Audacity

Audacity es una herramienta de software de grabación y edición de audio, mul-

tiplataforma, de libre uso y de código abierto. Permite grabar y reproducir audio,
y a su vez, permite exportar audio en formatos WAV, AIFF y MP3. Hoy en día es
uno de los programas gratuitos de edición de audio más fiable y más avanzado
para dicho fin [1].
Esta herramienta de software ofrece las posibilidades básicas de recortar, copiar y
pegar segmentos de señales de audio, pero además, permite trabajar varias pistas
a la vez, mezclarlas o aplicar diversos filtros y efectos sobre las señales. Estas
características hacen que esta herramienta sea ideal para trabajar en el desarrollo,
por ejemplo, para generar tonos puros y combinarlos. De esta forma, se eliminó
la necesidad de un generador de audio durante el desarrollo. En la figura 2.10 se
presenta el entorno de desarrollo del software Audacity.

1
http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu-ciaa-nxp
14 Capítulo 2. Introducción Específica

F IGURA 2.10: Entorno de desarrollo, Audacity.

2.7.3. MATLAB

MATLAB es una herramienta de software matemático que ofrece un entorno de

desarrollo integrado con un lenguaje de programación propio, el lenguaje m [9].
Esta herramienta fue utilizada a lo largo del desarrollo del trabajo para realizar
tareas de alto nivel. Con MATLAB, se caracterizaron y se diseñaron los filtros
FIR implementados mediante firmware. A su vez, MATLAB fue utilizado para
implementar tonos puros y para realizar el análisis de los resultados de los tests
realizados sobre los módulos desarrollados. En la figura 2.11 se presenta la herra-
mienta de software MATLAB.

F IGURA 2.11: Entorno de desarrollo, MATLAB.

2.8. Requerimientos 15

2.7.4. KiCad

KiCad es un paquete de software libre que se utiliza para la automatización de

diseño electrónico. Permite el diseño de esquemáticos para circuitos electrónicos
y facilita su conversión a PCB (Printed Circuit Board, Placa de Circuito Impreso).
Esta herramienta fue utilizada en el trabajo para llevar a cabo el diseño y la imple-
mentación del esquemático, el PCB y la documentación de fabricación del hard-
ware desarrollado. En la figura 2.12 se presenta la herramienta de software KiCad.

F IGURA 2.12: Entorno de desarrollo, KiCad.

2.8. Requerimientos

A continuación se presentan los requerimientos asociados a este trabajo.

1. Grupo de requerimientos asociados con la adquisición de audio.
a) El procesador de audio debe adquirir canal derecho e izquierdo del
audio proveniente de una consola o en su defecto de un micrófono.
b) Se debe adquirir con una frecuencia mínima de 44,1 kHz con una reso-
lución mínima de 10 bits.
2. Grupo de requerimientos asociados con el procesamiento del audio adqui-
rido.
a) El procesador debe filtrar canal izquierdo y canal derecho en 2 bandas
cada uno.
b) El procesador debe realizar una compresión rápida sobre cada banda
de los dos canales.
c) El procesador debe reconstruir los canales derecho e izquierdo a partir
de las bandas.
3. Grupo de requerimientos asociados con la generación de audio procesado.
16 Capítulo 2. Introducción Específica

a) Se deben reconstruir las señales de audio procesadas por el microcon-

trolador del canal derecho y del canal izquierdo.
b) Las señales de audio se deben reconstruir por medio de un DAC de
audio.
4. Grupo de requerimientos asociados al prototipo.
a) Mediante un interruptor se debe encender la alimentación del equipo.
b) Mediante un pulsador se debe iniciar y finalizar el procesamiento de
audio sin quitarle la alimentación al equipo.
c) Un led debe indicar que el equipo se encuentra encendido.
d) Un led debe indicar que el equipo se encuentra procesando audio.
e) Se deben utilizar tres leds como indicadores de magnitud de nivel de
tensión de entrada.
 17

Capítulo 3

Diseño e Implementación

En este capítulo se presenta la gestión del trabajo con el controlador de versiones,

el diseño e implementación del hardware desarrollado y el diseño e implementa-
ción de los distintos módulos de firmware que componen al procesador de audio.

3.1. Metodología de trabajo

En esta sección se describe el uso del control de versiones para realizar la gestión
del desarrollo y la documentación del trabajo.

3.1.1. Gestión del proyecto en Github

Para realizar el control de versiones y la gestión del trabajo se eligió utilizar el

controlador de versiones Github1 . Se realizó la elección de Github en lugar de
sus competidores ya que fue utilizado durante la Carrera de Especialización en
Sistemas Embebidos. Además, es utilizado por el autor de esta memoria para su
actividad profesional. De esta forma, todo lo aprendido para este trabajo puede
ser aprovechado para la actividad profesional y viceversa.
Se puede ingresar al repositorio del trabajo mediante la url: https://github.com/
gastonvallasciani/procesadorDeAudio.
Github brindó al desarrollo del trabajo de un sistema de control de versiones
GIT. Como modelo de gestión de ramas se utilizó el criterio que se describe a
continuación. Como rama principal se utiliza la rama master. Cuando es necesa-
rio implementar una funcionalidad nueva se genera una rama del tipo develop
con la nomenclatura "developNombreFuncionalidad". Una vez implementada la
nueva funcionalidad se genera, a partir de la rama develop, una rama del tipo de-
velopOffline con la nomenclatura "developNombreFuncionalidadOffline". En esta
rama se realizan testeos a partir de un módulo de firmware implementado para
dicho fin. Una vez finalizado el testeo offline se realiza un merge a la rama del tipo
develop y se elimina la rama developOffline. Luego se genera una rama del tipo de-
velopOnline con la nomenclatura "developNombreFuncionalidadOnline". En esta
rama se realiza un testeo con una entrada externa al dispositivo. Una vez efec-
tuado este testeo se realiza un merge a la rama develop y se elimina la rama del
tipo developOnline. Una vez hecho esto se hace un merge de la rama develop a la
rama master y se elimina la rama develop. De esta forma, la rama master siempre

1
https://github.com
18 Capítulo 3. Diseño e Implementación

tiene una versión estable del proyecto. El modelo de gestión de ramas utilizado
se presenta en la figura 3.1.

F IGURA 3.1: Modelo de gestión de ramas utilizado.

A partir de la rama master se generan las versiones nuevas del equipo. La versión
del equipo tiene la nomenclatura Y.X donde Y representa el número de versión y
X la revisión por bug.
Si se debe corregir un bug importante se abre nuevamente una rama del tipo de-
velop, se corrige y se realiza un merge a la rama master, luego se debe cerrar una
versión del tipo Y.(X+1).
En el desarrollo de este trabajo se generaron las ramas: developFilter, develop-
FilterOnline, developFilterOffline, developCompressor, developCompressorOf-
fline, developBandsProcessing, developUserInterface.
Algunas de las ramas mencionadas se presentan en la figura 3.2.

3.1.2. Documentación

Normalmente, cuando se realiza un desarrollo, el proyecto se almacena en un

sistema de control de versiones mientras que la documentación se aloja en una
computadora o en algún otro dispositivo. Al estar el proyecto de firmware y la
documentación por separado, es posible que ésta se pierda. Por lo tanto, resulta
de interés realizar la documentación en conjunto con el proyecto de firmware.
3.1. Metodología de trabajo 19

F IGURA 3.2: Ramas generadas durante el desarrollo del trabajo.

Mediante el archivo README.md se realizó un seguimiento del trabajo. En éste

se actualizaron problemas o cambios importantes realizados en distintos momen-
tos del desarrollo, con su fecha. A su vez, se utilizó la wiki que provee Github para
documentar los aspectos técnicos del trabajo2 . La implementación de la wiki se
presenta en la figura 3.3.

F IGURA 3.3: Wiki de github.

2
https://github.com/gastonvallasciani/procesadorDeAudio/wiki
20 Capítulo 3. Diseño e Implementación

3.2. Firmware de procesamiento de Audio

En esta sección se describe el diseño y la implementación del firmware para efec-

tuar el procesamiento de audio que implementa el equipo desarrollado.

3.2.1. Máquina de estados del procesador de audio

El procesador de audio ejecuta procesos de forma secuencial. Cada proceso debe

haber finalizado antes de ejecutar el siguiente. Teniendo en cuenta este modo de
funcionamiento se implementó un despachador de procesos por medio de una
FSM (Finite State Machine, Máquina de Estados Finitos). La transición de estados
ocurre cuando finaliza el procesamiento del vector de datos de entrada.
Los estados correspondientes a la FSM implementada se presentan en la figura
3.4.

F IGURA 3.4: Máquina de estados del procesador de audio.

La funcionalidad de cada uno de los estados de la FSM del procesador de audio

es la siguiente:
Level detector: estado de detección de nivel de entrada utilizado en la interfaz
de usuario para realizar la indicación de nivel mediante las luces led de
color rojo, amarillo y verde.
Audio processing delay: estado que implementa un retardo para sincronizar
la adquisición de la señal de audio con la generación de audio.
Gain control: estado que implementa una ganancia sobre la señal de entrada.
LPF 15 kHz filter: estado que implementa un filtro FIR pasabajos con una
frecuencia de corte de 15 kHz.
3.2. Firmware de procesamiento de Audio 21

Peak symmetrizer: estado que implementa el simetrizador de picos. Éste es

implementado por medio de un compresor lento.
Band split: estado que ejecuta la división de la señal de audio de entrada
en dos bandas mediante un filtro crossover implementado con un filtro FIR
pasabajos y un filtro FIR pasaaltos cuya frecuencia de encuentro es de 5
kHz.
Fast compressor: estado que implementa un compresor rápido sobre las ban-
das.
Sum bands: estado que implementa la función de suma de bandas.
Clipper: recorta la señal de audio reconstruida cuando su amplitud supera
un nivel predefinido.

3.2.2. Adquisición y generación de audio

Para realizar la adquisición y generación de audio se utilizó un ADC y un DAC

pertenecientes al microcontrolador LPC4337 presente en la EDU-CIAA NXP. Este
microcontrolador posee un DAC de resolución de 10 bits con soporte DMA y
una velocidad de conversión máxima de 400 kHz. Además posee dos ADC de
resolución de 10 bits, con soporte DMA, velocidad de conversión máxima de 400
kHz y permite seleccionar hasta 8 canales por ADC [10].
Para realizar la adquisición de audio se utilizó el ADC 0 multiplexado al canal 3
del microcontrolador. Éste se configuró con una frecuencia de adquisición de 400
kHz, una resolución de 10 bits y se temporizó la adquisición mediante el TIMER
0 para adquirir a una frecuencia de 44,1 kHz.
Para realizar la generación de audio se utilizó el DAC configurado con una fre-
cuencia de adquisición de 400 kHz, una resolución de 10 bits y se temporizó la
generación mediante el TIMER 1 para generar la señal con la frecuencia de ad-
quisición.
Debido a la alta frecuencia de muestreo y por lo tanto al gran volumen de datos
adquiridos, resultó necesario utilizar una técnica para adquirir, procesar y gene-
rar audio de forma sincronizada. Para ello se utilizó la técnica de Double Buffering
o más comúnmente llamado ping-pong buffer.
Un diagrama del sistema de adquisición y generación utilizado se presenta en la
figura 3.5. En verde se observan los periféricos utilizados del microcontrolador,
en azul los drivers de los patrones de diseño implementados y los driver de las
interrupciones de los timers utilizados y en rojo la implementación del ping-pong
buffer.

Implementación ping-pong buffer

La implementación del ping-pong buffer consiste en utilizar un buffer para adquirir

datos y otro buffer para procesar datos simultáneamente. Al buffer de adquisición
se lo denomina background buffer mientras que al buffer de procesamiento se lo
denomina active buffer.
22 Capítulo 3. Diseño e Implementación

F IGURA 3.5: Sistema de adquisición y generación de audio.

El background buffer se actualiza mediante el CANAL 0 del ADC. La carga del

mismo se encuentra temporizada y efectuada mediante la interrupción de des-
borde del TIMER 0.
Cuando finaliza el procesamiento de datos se copia el vector de datos procesado
al vector de salida o vector de generación de audio.
Luego, una vez que el background buffer se llena, se realiza el intercambio entre
el background buffer y el active buffer. Entonces el background buffer comienza a
cargar datos nuevamente y el procesamiento comienza en el active buffer con el
nuevo vector de datos.
La generación de audio debe finalizar al instante que finaliza el procesamiento
de datos. De esta forma la generación de audio se efectúa de forma continua. En
la figura 3.6 se presenta un diagrama de flujo del funcionamiento del ping-pong
buffer.
3.2. Firmware de procesamiento de Audio 23

F IGURA 3.6: Diagrama de flujo del ping-pong buffer.

 24 Capítulo 3. Diseño e Implementación

Implementación del patrón de diseño

Para realizar la abstracción de hardware sobre el DAC y el ADC, se utilizó el pa-

trón de diseño Hardware Proxy Pattern. De esta forma, se separararon los bloques
de procesamiento de audio de la adquisición y la generación.
Para el ADC, el patrón de diseño se implementó en el código mediante el módulo
ADC_hardwareProxy.
En el módulo ADC_hardwareProxy se implementaron funciones presentes en el
algoritmo 3.1:
1
2 void a d c I n i t i a l i z e (LPC_ADC_T ∗ channel ) ;
3
4 void a d c C o n f i g u r a t i o n (LPC_ADC_T ∗ channel , adcHardwareProxyConfigMode_t
mode ,ADC_CHANNEL_T adcMultiplexedChannel , u i n t 3 2 _ t adcSampleRate ,
uint8_t resolution ) ;
5
6 void a d c D i s a b l e (LPC_ADC_T ∗ channel ) ;
7
8 void a d c S e t (LPC_ADC_T ∗ channel , ADC_CHANNEL_T adcMultiplexedChannel ,
u i n t 3 2 _ t sampleRate , u i n t 8 _ t r e s o l u t i o n , u i n t 8 _ t a c t i o n ) ;
9
10 u i n t 8 _ t adcReadData (LPC_ADC_T ∗ channel , adcHardwareProxyConfigMode_t
mode ,ADC_CHANNEL_T adcMultiplexedChannel , u i n t 1 6 _ t ∗ adcData ) ;
A LGORITMO 3.1: Funciones implementadas del módulo
ADC_hardwareProxy

El funcionamiento de las funciones implementadas es el siguiente:

adcInitialize(): cumple la función de initialize() , inicializa el canal del ADC.
adcConfiguration(): cumple la función de configure(), configura el modo
de funcionamiento, el canal multiplexado, la frecuencia de muestreo y la
resolución.
adcDisable(): cumple la función de disable(), deshabilita el canal del ADC.
adcSet(): cumple la función de mutate(), y se utiliza para modificar el modo
de funcionamiento, el canal multiplexado, la frecuencia de muestreo o la
resolución.
adcReadData(): cumple la función de access(), adquiere del ADC el valor
digitalizado por el mismo.
A su vez, para el DAC, el patrón de diseño se implementó en el código mediante
el módulo DAC_hardwareProxy.
 3.2. Firmware de procesamiento de Audio 25

En el módulo DAC_hardwareProxy se implementaron las funciones presentes en

el algoritmo 3.2.
1
2 void DACHARDWAREPROXY_initialize ( void ) ;
3
4 void DACHARDWAREPROXY_config( void ) ;
5
6 void DACHARDWAREPROXY_disable( void ) ;
7
8 u i n t 8 _ t DACHARDWAREPROXY_marshal( void ) ;
9
10 u i n t 8 _ t DACPROXYCLIENT_mutate ( u i n t 1 6 _ t data ) ;
A LGORITMO 3.2: Funciones implementadas del módulo
DAC_hardwareProxy

El funcionamiento de las funciones implementadas es el siguiente:

DACHARDWAREPROXY_initialize(): cumple la función de initialize() , ini-
cializa el canal del DAC.
DACHARDWAREPROXY_config(): cumple la función de configure(), con-
figura la operación DMA.
DACHARDWAREPROXY_disable(): cumple la función de disable(), desha-
bilita el canal del DAC.
DACHARDWAREPROXY_marshal(): cumplen la función de marshal(), ac-
tualiza el valor en un buffer circular interno del driver.
DACPROXYCLIENT_mutate(): cumple la función de mutate(), actualiza el
valor generado por el DAC a partir del buffer circular.

3.2.3. Implementación de filtros para procesamiento de audio

Filtro pasabajos 15 kHz

Para el desarrollo de los filtros utilizados en el equipo se utilizó la herramienta

fdatool (filter design and analysis tool) de MATLAB.
En primer lugar se diseñó un filtro FIR pasabajos. Para ello se configuró la herra-
mienta fdatool con los siguientes parámetros:
Design method: equiripple (Parks Mcclellan).
Filter order: minimum order.
Fs: 44100 Hz.
Fpass: 15 kHz.
Fstop: 19 kHz.
Apass: 1 dB.
Astop: 60 dB.
26 Capítulo 3. Diseño e Implementación

Mediante estos parámetros se obtuvo un filtro FIR de orden 21, cuyos coeficientes
son los siguientes: -423, 279, 910, -660, 658, 489, -1707, 2557, -1636, -2467, 19183,
19183, -2467, -1636, 2557, -1707, 489, 658, -660, 910, 279, -423.
La respuesta en frecuencia del filtro diseñado se presenta en la figura 3.7. En ésta
se observa que en la frecuencia de 19 kHz el filtro atenúa 60 dB a la señal de
entrada, condición necesaria para transmitir una señal de audio por medio de un
transmisor de FM.

F IGURA 3.7: Respuesta en magnitud del filtro diseñado.

La respuesta en fase del filtro diseñado se presenta en la figura 3.8. En ésta se

observa que el filtro diseñado posee fase lineal en la banda de paso.

F IGURA 3.8: Respuesta en fase del filtro diseñado.

A su vez, en la figura 3.9 se presenta el retardo de grupo y en la 3.10 se presenta

el retardo en fase. En éstas se observa que el filtro diseñado posee un retardo de
grupo constante y un retardo de fase igual a cero. Esto implica que la señal no se
encuentra retardada en fase a la salida del filtro. Por lo tanto, el filtro no introduce
distorsión a la señal de entrada.
Por último, en la figura 3.11 se presenta la respuesta al escalón del filtro diseñado.
Ésta caracteriza completamente al filtro diseñado.
3.2. Firmware de procesamiento de Audio 27

F IGURA 3.9: Retardo de grupo del filtro diseñado.

F IGURA 3.10: Retardo de fase del filtro diseñado.

Filtro crossover

El filtro crossover fue diseñado mediante dos filtros: un filtro FIR pasabajos y un
filtro FIR pasaaltos. Éstos fueron diseñados mediante la herramienta fdatool de
MATLAB.
Para el diseño del filtro pasabajos se configuraron los siguientes parámetros.
Design method: equiripple (Parks Mcclellan).
Filter order: minimum order.
Fs: 44100 Hz.
Fpass: 2000 Hz.
Fstop: 8000 Hz.
Apass: 1 dB.
Astop: 40 dB.
28 Capítulo 3. Diseño e Implementación

F IGURA 3.11: Retardo de fase del filtro diseñado.

A su vez, para el diseño del filtro pasaaltos se configuraron los siguientes pará-
metros.
Design method: equiripple (Parks Mcclellan).
Filter order: minimum order.
Fs: 44100 Hz.
Fpass: 8000 Hz.
Fstop: 2000 Hz.
Apass: 1 dB.
Astop: 40 dB.
Una vez diseñados, se obtuvo un filtro de orden 10 para el filtro pasabajos y un fil-
tro de orden 9 para el filtro pasaaltos. Los coeficientes obtenidos de ambos filtros
son los siguientes:
Coeficientes filtro FIR pasabajos: 507, 1926, 3513, 5342, 6418, 6418, 5342,
3513, 1926, 507.
Coeficientes filtro FIR pasaaltos: 1474, 66, -1879, -4740, -7322, 24408, -7322,
-4740, -1879, 66, 1474.
En la figura 3.12 se presenta la respuesta en amplitud de ambos filtros en un mis-
mo gráfico. En ésta se observa que el cruce de la respuesta en frecuencia de ambos
filtros se produce en 5 kHz aproximadamente. A esta frecuencia se subdivide la
banda de 15 kHz en dos bandas independientes. Una banda se encuentra com-
prendida en el rango de 0 a 5 kHz, mientras que la otra banda se encuentra en el
rango de frecuencias de 5 kHz a 15 kHz.
En la figura 3.13 se presenta la respuesta en fase de ambos filtros. Como se puede
observar ambos filtros poseen una respuesta en fase lineal en la banda de paso.
Por último, al igual que el filtro pasabajos de 15 kHz, los filtros que forman parte
del crossover poseen retardo en fase nulo, mientras que el retardo de grupo es un
valor constante.
3.2. Firmware de procesamiento de Audio 29

F IGURA 3.12: Respuesta en magnitud de los filtros diseñados.

F IGURA 3.13: Respuesta en fase de los filtros diseñados.

3.2.4. Compresor de audio

Se implementó un driver de alto nivel que se encarga de efectuar la operación de

compresión. En este driver se implementaron cuatro parámetros configurables:
El umbral.
La relación de compresión.
El tiempo de ataque.
El tiempo de relajación.
El compresor de audio fue implementado mediante una FSM. Esta FSM se en-
cuentra conformada por tres estados: “DISABLE_STATE”, “ATTACK_STATE” y
el estado “RELEASE_STATE”. La FSM implementada se presenta en la figura
3.14.
30 Capítulo 3. Diseño e Implementación

F IGURA 3.14: FSM del compresor de audio.

El funcionamiento de los estados de la FSM del compresor de audio se describe a

continuación.
DISABLE_STATE: es el estado de reposo. Mientras que el nivel de entrada
no supere q el nivel umbral, el compresor no actúa. Una vez que el nivel
de entrada supera el valor umbral se produce el “gatillado” y se produce la
transición al estado ATTACK_STATE.
ATTACK_STATE: se efectúa la compresión de la señal de entrada de forma
gradual hasta alcanzar la compresión máxima. El tiempo de duración de
la compresión de la señal se encuentra limitado por el tiempo de ataque.
Cuando se ingresa en el estado se inicia la cuenta de tiempo en la que se
encuentra en el estado ATTACK_STATE, cuando se alcanza el tiempo de
ataque se efectúa la transición al estado RELEASE_STATE.
RELEASE_STATE: se efectúa la descompresión controlada de la señal par-
tiendo de la compresión máxima. El tiempo de duración de la descompre-
sión del nivel de entrada se encuentra limitado por el tiempo de relajación.
Cuando se ingresa en el estado se inicia la cuenta de tiempo en la que se
encuentra en el estado RELEASE_STATE, cuando se alcanza el tiempo de
relajación se efectúa la transición de estados al estado DISABLE_STATE.
La compresión máxima depende del nivel de entrada, el umbral y la relación
de compresión. Se calcula cada vez que se efectúa el “gatillado” en el DISA-
BLE_STATE. El cálculo se efectúa según la ecuación 3.1.

nivel de entrada − umbral

compresión máxima = + umbral (3.1)
relación de compresión
3.3. Hardware 31

El compresor de audio lento se configuró con un tiempo de ataque de 25 ms y un

tiempo de relajación de 250 ms. Además se configuró la relación de compresión en
2 y el umbral en 700. El umbral es equivalente a 1,13 V a la entrada del ADC. Para
el compresor de audio rápido se configuró con un tiempo de ataque de 3 ms y un
tiempo de relajación de 30 ms. A su vez, se configuró la relación de compresión
en 2 y el umbral en 750. El umbral es equivalente a 1,21 V a la entrada del ADC.

3.3. Hardware

3.3.1. Análisis de los circuitos más importantes

Para realizar la adquisición de audio fue necesario implementar el circuito de

acondicionamiento de señal que se presenta en la figura 3.15.
El circuito de la figura 3.15 implementa un mezclador de audio con amplificación.
A este circuito se le ingresa con el canal derecho e izquierdo de una señal de
audio proveniente de una consola o un micrófono en INRCHM y en INLCHM,
respectivamente.
A estas señales de audio se las atenua mediante los divisores resistivos conforma-
dos por R16 con R18 y R17 con R19. Luego su contenido de continua es filtrado
mediante los capacitores C9 y C10.
Debido a que el ADC sólo puede adquirir señales positivas, fue necesario sumar
un offset de continua a la señal de audio entrante. Ésto se implementó mediante
las resistencias R13, R14 y la resistencia variable R15. A través de la resistencia
R15 el operador puede ajustar el offset durante el proceso de puesta en marcha
del equipo.
En el pin 3 del amplificador operacional U2A se realiza la suma del canal izquier-
do, canal derecho y el offset de continua. Luego, la señal resultante es inyectada
en el amplificador operacional sobre el cual se implementa una configuración no
inversora, conformada por R20 y R36.
Además se agregó el jumper CH3ADC a la salida del amplificador U2A. Éste
jumper permite al operador separar la etapa de acondicionamiento del micro-
controlador durante el proceso de puesta en marcha. De esta forma se protege
al microcontrolador de posibles aumentos de tensión inesperados en su entrada
ADC.
Para la generación de audio se implementó el circuito de la figura 3.16. En este
circuito se implementó un filtro pasaaltos con una frecuencia de corte de 100 Hz.
El filtro es utilizado para eliminar el nivel de continua de la señal de audio gene-
rada por el DAC del uC. No se incluyó el circuito de reconstrucción ya que fue
dejado para una etapa posterior del trabajo porque es un circuito analógico que
debe ser analizado de forma unitaria.
Por último, para utilizar en conjunto con la interfaz de usuario se agregaron tres
led cuyo circuito se presenta en la figura 3.17. Estos led son activados por medio
de las salidas digitales GPIO4, GPIO5 y GPIO6 del microcontrolador presente en
la EDU-CIAA NXP.
32 Capítulo 3. Diseño e Implementación

F IGURA 3.15: Circuito de acondicionamiento de la señal para la

adquisición de audio.

3.3.2. Diseño de circuito impreso

Los circuitos implementados en la subsección 3.3.1 fueron implementados me-

diante un PCB (Printed Circuit Board, Placa de circuito impreso).
El PCB y el esquemático fueron diseñados haciendo uso del software kiCad. El
PCB fue desarrollado a modo de poncho para ser montado sobre la EDU-CIAA
NXP. A éste se le dio el nombre de "Poncho procesador de audio 3 ". Para realizar
este diseño se tuvieron en cuenta los siguientes aspectos:
Accesibilidad a los conectores de entrada y salida del procesador.
Cercanía de capacitores de filtrado a los pines de alimentación de los circui-
tos integrados.
Visualización de los leds de la EDU-CIAA NXP.
3
https://github.com/gastonvallasciani/CESE-6Co2018_PCB
3.4. Interfaz de usuario 33

F IGURA 3.16: Circuito de generación de audio por medio del

DAC.

F IGURA 3.17: Circuito de manejo de leds para interfaz de usuario.

Orden en la ubicación de los componentes.

Puesta en marcha del equipo.
El modelo 3D del poncho desarrollado se presenta en la figura 3.18.
El PCB fue fabricado en Argentina por la empresa Ernesto MAYER SA y la mon-
tura de componentes fue realizada por el autor de esta memoria. La implementa-
ción final con los componentes montados se presenta en la figura 3.19.

3.4. Interfaz de usuario

Para que el operador interactúe con el procesador de audio se implementó una

interfaz de usuario por medio de la tecla TEC1, un interruptor y los leds LED1,
LED2, LED 3, D2 y el LEDR.
Una vez que se enciende el procesador de audio, el procesamiento de audio se en-
cuentra deshabilitado. D2 se encuentra apagado, LEDR se encuentra encendido,
LED1 se encuentra encendido, LED2 se encuentra apagado y LED3 se encuentra
apagado. Cuando LEDR se encuentra encendido indica que el equipo se encuen-
tra en funcionamiento.
34 Capítulo 3. Diseño e Implementación

F IGURA 3.18: Modelo 3D PCB desarrollado.

3.4. Interfaz de usuario 35

F IGURA 3.19: PCB fabricado con componentes montados.

Para iniciar el procesamiento de audio se utiliza el pulsador TEC1 presente en la

placa EDU-CIAA NXP. Para que la ejecución de la acción de pulsado sea inde-
pendiente de la dinámica secuencial de ejecución de instrucciones del programa
se utilizó la interrupción de cambio de nivel. Esta interrupción se configuró para
que detecte el flanco descendente generado cuando se presiona el pulsador TEC1.
Una vez pulsado TEC1 se enciende el led D2 que indica que el equipo se encuen-
tra procesando audio. Si se desea finalizar el procesamiento de audio se debe
pulsar nuevamente TEC1. Una vez finalizado el procesamiento de audio el led
D2 se apaga.
Los leds LED1, LED2 y LED3 son utilizados para indicar en qué rango se encuen-
tra el nivel de entrada. El detector de nivel es quién se encarga de sensar el nivel
de entrada y cuando éste es menor a 341 se enciende el LED3 y se apagan LED1 y
LED2, cuando se encuentra entre 341 y 682 se enciende LED2 y se apagan LED1 y
LED3 y cuando es superior 682 y menor a 1023 a se enciende el LED1 y se apagan
LED1 y LED3.
El detector de nivel se encuentra en funcionamiento todo el tiempo que el equipo
se encuentre encendido. Ésto se debe a que el detector de nivel se utiliza para
ajustar el nivel de entrada durante la calibración del equipo. Además, al aplicarse
36 Capítulo 3. Diseño e Implementación

el detector de nivel sobre cada muestra adquirida y teniendo en cuenta que el

equipo adquiere con una frecuencia de 44,1 kHz, los tres led funcionan como un
vúmetro de tres niveles. Esto es debido a que según se evalué el nivel de entrada
de las muestras adquiridas, se actuará sobre los leds produciendo un encendido
audio rítmico de los mismos.
La ubicación de los componentes que forman parte de la interfaz de usuario se
presenta en la figura 3.20. En ésta se observa el pulsador TEC1 en un recuadro
amarillo, los leds LED1, LED2 y LED3 en un recuadro verde y el led LEDR en
un recuadro rosa. El led D2 se encuentra ubicado en el poncho de la figura 3.19
presente en la subsección 3.3.1.

F IGURA 3.20: Ubicación de los componentes de la interfaz de

usuario.
 37

Capítulo 4

Ensayos y Resultados

En esta sección se exponen los ensayos que se llevaron a cabo a lo largo del desa-
rrollo del trabajo y los resultados obtenidos a partir de los mismos. Cada módulo
de firmware implementado fue ensayado de forma unitaria, y además, se realizó
un test integral del funcionamiento del equipo.

4.1. Adquisición y generación de audio

Para llevar a cabo este test se utilizaron los siguientes instrumentos:

Generador de audio: GW Instek GAG-810. Rango de frecuencia de 10 Hz a
1 MHz.
Osciloscopio: GW Instek GDS-1102A-U.
Analizador de espectros: USB-SA44B - 4.4 GHz. Signal Hound.
Este test fue realizado para caracterizar el ADC y el DAC utilizados en el trabajo.
Para ello se midió la latencia que existe entre la adquisición y la generación de
audio y la distorsión armónica que introduce el DAC al reconstruir la señal de
audio.
Para realizar el test unitario de adquisición y generación de audio se armó un
circuito de acondicionamiento de señal sobre una protoboard. Por medio de éste
se sumó un nivel de continua a un tono puro generado por el generador de audio.
El circuito acondicionador fue conectado al Canal 0 del ADC. El circuito montado
para realizar este test es el que se presenta en la figura 3.15.
Durante el test se inyectó al circuito acondicionador de señal un tono puro de
frecuencia 15 kHz y amplitud 3 V. Se utilizó una velocidad de conversión y gene-
ración de 44,1 kHz. Luego, se midió la señal reconstruida sobre la salida del DAC
con un osciloscopio. De esta forma, se obtuvo la lectura del osciloscopio que se
presenta en la figura 4.1. En ésta se observa en azul la señal inyectada, mientras
que en amarillo se presenta la señal de salida del equipo.
En la figura 4.1 se observa que existe una latencia entre adquisición y generación
de 12 uS. Además, se observa que la señal de salida difiere en gran medida y es
escalonada con respecto a la señal de entrada. Ésto es debido a que se muestrea y
se reconstruye la señal de entrada con una frecuencia 3 veces mayor con respecto
a la frecuencia del tono inyectado. Esto produce que se tomen pocas muestras por
periodo de la señal de entrada, perdiendo información de la misma y generando
diferencias al reconstruirla.
38 Capítulo 4. Ensayos y Resultados

F IGURA 4.1: Medición de latencia mediante osciloscopio.

Luego, se midió la salida del DAC con el analizador de espectro y se obtuvo la

lectura que se presenta en la figura 4.2.

F IGURA 4.2: Medición de distorsión armónica mediante analiza-

dor de espectro.

En la figura 4.2 se observa que entre la componente fundamental y la tercer ar-

mónica hay una diferencia de 54,4 dB. Por lo tanto, piso de ruido se encuentra
limitado por la tercer armónica y establece el piso de ruido mínimo que posee el
equipo.
4.2. Filtros 39

4.2. Filtros

Para realizar el test unitario de cada uno de los filtros diseñados para el procesa-
dor de audio se armó un banco de pruebas. El banco de pruebas armado utilizó
los siguientes instrumentos:
PC con software Audacity.
Osciloscopio UNI-T UTD2102CEX, 100 MHz, 1 GS/s.
El diagrama en bloques del banco de pruebas de filtros se presenta en la figura 4.3.
En ésta se observa que una PC se encuentra conectada a la entrada del procesador
de audio. Por medio de la PC y utilizando el software Audacity se generaron los
tonos puros necesarios para realizar las pruebas sobre los filtros. A su vez, a la
salida del procesador se conectó un parlante. Por último, se conectó el canal 1
del osciloscopio a la entrada del procesador y el canal 2 a la salida. Para este test,
en el procesador de audio se implementó únicamente la adquisición de audio, la
generación de audio y el algoritmo de procesamiento del filtro estudiado.

F IGURA 4.3: Banco de pruebas de filtros.

Para efectuar el test del filtro pasabajos con frecuencia de corte de 15 kHz se inyec-
taron tonos puros de 1, 10, 14 y 19 kHz. De esta forma, se inyectaron cuatro tonos
que se encuentran en el rango de frecuencias de la banda de paso del filtro y un
tono que se encuentra al inicio de la banda de stop. No se tomó una mayor can-
tidad de tonos dentro de la banda de stop ya que al generar tonos de frecuencias
mayores a 20 kHz la salida de audio de la PC se volvió inestable imposibilitando
la medición.
Una vez inyectados los tonos puros, se midió y se comparó por medio del osci-
loscopio la entrada y la salida del procesador de audio. De esta forma, se verificó
la respuesta en magnitud del filtró diseñado en la subsección 3.2.3. Las lecturas
obtenidas del osciloscopio al ingresar los tonos de entrada se observan en las fi-
guras 4.4, 4.5, 4.6 y 4.7. En éstas se presenta en amarillo la señal de entrada al
procesador y en azul la señal de salida.
En la figura 4.4 se observa que no hay variación entre entrada y salida. Ésto se
condice con las características del filtro diseñado en la subsección 3.2.3.
En la figura 4.5, al igual que en la figura 4.4 no se observa una variación de mag-
nitud significativa.
En la figura 4.6 se observa una variación entre la entrada y la salida. Esta se debe
en primer lugar al error que se produce al muestrear el tono con una cantidad
40 Capítulo 4. Ensayos y Resultados

F IGURA 4.4: Entrada comparada con salida del procesador de au-

dio con tono de 1 kHz.

F IGURA 4.5: Entrada comparada con salida del procesador de au-

dio con tono de 10 kHz.

de muestras pequeña por periodo. En segundo lugar se debe a que al codificar

se debieron truncar los coeficientes del filtro diseñado originalmente para pasar
de números flotantes a enteros. Además, se observa que la señal de salida se en-
cuentra montada sobre una señal de baja frecuencia. Esta frecuencia es un efecto
indeseado del muestreo introducido por el osciloscopio.
Por último, en la figura 4.7 se observa la respuesta en magnitud del filtro en la
banda de stop. En ésta se observa que la señal de entrada fue atenuada en gran
medida por parte del filtro. De esta forma, se corrobora que el filtro posee el com-
portamiento esperado.
4.2. Filtros 41

F IGURA 4.6: Entrada comparada con salida del procesador de au-

dio con tono de 14 kHz.

F IGURA 4.7: Entrada comparada con salida del procesador de au-

dio con tono de 19 kHz.

Los filtros que forman parte del filtro crossover fueron probados, de forma inde-
pendiente, con la misma metodología aplicada para el filtro pasabajos de 15 kHz.
Se corroboró un comportamiento adecuado de los mismos que se condice con los
filtros diseñados en la subsección 3.2.3.
42 Capítulo 4. Ensayos y Resultados

4.3. Compresor de audio

Para realizar el test unitario del módulo de compresión de audio se implementó

el mismo banco de pruebas que en la sección 4.2.
En el procesador de audio se implementó únicamente la adquisición de audio, la
generación de audio y el algoritmo de compresión de audio.
Para llevar a cabo el test se configuró un compresor de audio con los siguientes
parámetros:
Umbral: 600.
Relación de compresión: 2.
Tiempo de ataque: 30 ms.
Tiempo de relajación: 30 ms.
Una vez configurado el compresor de audio, se inyectó un tono puro de 5 kHz en
la entrada del procesador de audio. El tono inyectado se presenta en la figura 4.8.

F IGURA 4.8: Tono de 5 kHz generado con Audacity para test de

compresor de audio.

Como se puede observar en la figura 4.8 la amplitud del tono aumenta luego de
un tiempo. De esta forma se forzó el “gatillado” del compresor de audio.
Luego, se midió la salida del compresor de audio mediante el osciloscopio. En la
figura 4.9 se presenta la medición del tiempo de ataque sobre la señal procesada
por el compresor de audio, mientras que en la figura 4.10 se presenta la medición
del tiempo de relajación.
En la figura 4.9 se observa que el compresor de audio no actúa hasta que se pro-
duce el “gatillado”. Luego, comienza la compresión de la señal de entrada hasta
un nivel de compresión máxima. El nivel de compresión máxima se encuentra
dado por la ecuación 3.1. La compresión se produce durante el tiempo de ata-
que que es igual a 30 ms. El tiempo de ataque medido en la figura 4.9 es igual al
configurado como parámetro del compresor de audio.
En la figura 4.10 se observa que luego de la compresión de la señal de entrada, se
produce la descompresión controlada hasta el nivel original de la señal de entra-
da. La descompresión se produce por un tiempo de 30 ms. El tiempo de relajación
medido en la figura 4.10 es igual al configurado como parámetro del compresor
de audio.
El funcionamiento del compresor se condice con el funcionamiento del compre-
sor presentado en la subsección 3.2.4. El compresor de audio no actúa hasta que
4.4. Ensayo integrador 43

F IGURA 4.9: Medición del tiempo de ataque sobre la señal proce-

sada por el compresor de audio.

el nivel de entrada supera el nivel umbral, entonces se produce el “gatillado”.

Luego, la señal de entrada es comprimida durante el tiempo de ataque hasta el
nivel de compresión máxima. Por último, la señal es descomprimida de forma
controlada por el tiempo de relajación hasta su nivel original.

4.4. Ensayo integrador

Se realizó el test integrador del equipo. Para éste se utilizó el procesador de au-
dio con la totalidad de los módulos de firmware. La salida de audio de la PC se
conectó a la entrada del procesador de audio. Además, se conectó el osciloscopio
entre la entrada y la salida del procesador. En la figura 4.11 se presenta el banco
de pruebas montado.
En primer lugar se midió la latencia del equipo. La medición fue realizada por
firmware contando la cantidad de ciclos de reloj que conlleva ejecutar el ciclo
completo entre adquisición y generación de audio. La cantidad resultante de ci-
clos de reloj fue de 7100944. Este valor es equivalente a 34,8 ms y resulta superior
a la latencia del equipo ORBAN presentado en la tabla 1.1.
Luego, se inyectó música para ajustar los parámetros del equipo. Los paráme-
tros configurados para el compresor de audio del simetrizador de picos son los
siguientes:
Umbral: 700.
Relación de compresión: 2.
Tiempo de ataque: 25 ms.
Tiempo de relajación: 250 ms.
44 Capítulo 4. Ensayos y Resultados

F IGURA 4.10: Medición del tiempo de relajación sobre la señal

procesada por el compresor de audio.

A su vez, los parámetros configurados para los compresores rápidos fueron los
siguientes:
Umbral: 750.
Relación de compresión: 2.
Tiempo de ataque: 3 ms.
Tiempo de relajación: 30 ms.
Por último, el umbral del clipper fue configurado en 800.
En la figura 4.12 se presenta una imagen cualitativa de la lectura del osciloscopio
con la configuración descripta final del equipo. En el canal 1, en azul, se visualiza
la salida del equipo, mientras que en el canal 2, en amarillo, se visualiza la entrada
de audio del equipo. En la figura 4.12 se observa que la salida fue amplificada con
respecto en la entrada. Esto se condice con el estado de amplificación de la FSM
general del procesador de audio de la figura figura 3.4.

4.5. Resumen de los resultados

A continuación en la tabla 4.1 se muestra una lista de los requerimientos iniciales

y su grado de conformidad. Los requerimientos que se encuentran incompletos
fueron pospuestos para la siguiente etapa del proyecto.
4.5. Resumen de los resultados 45

F IGURA 4.11: Banco de pruebas del ensayo integrador.

F IGURA 4.12: Lectura del osciloscopio resultante del ensayo inte-

grador.
46 Capítulo 4. Ensayos y Resultados

TABLA 4.1: Tabla de conformidad de los requerimientos.

Req Conformidad Observaciones

R1.a Completa -
R1.b Completa -
R2.a Parcial Actualmente se adquieren sumados los dos canales.
R2.b Completa -
R2.c Completa -
R3.a Completa -
R3.b Incompleta Se dejó para la siguiente etapa del proyecto.
R4.a Completa -
R4.b Completa -
R4.c Completa -
R4.d Completa -
R4.e Completa -
 47

Capítulo 5

Conclusiones

En este capítulo se realiza una conclusión general sobre el trabajo realizado y se

detallan los pasos a seguir en el futuro.

5.1. Trabajo realizado

En la presente memoria se documentó el desarrollo del prototipo de un procesa-

dor de audio digital para radio emisoras FM.
Los requerimientos planteados al principio del trabajo fueron llevados a cabo
en su mayoría, exceptuando aquellos que fueron pospuestos para una segunda
etapa. Estos requerimientos son el 3.b y el 2.a.
Para el desarrollo de este trabajo se utilizaron técnicas y conceptos aprendidos du-
rante las distintas materias de la Especialización en Sistemas Embebidos (CESE).
A continuación se resaltan los contenidos que mayor relevancia tuvieron para el
desarrollo de este trabajo:
Se utilizaron conocimientos sobre la Arquitectura ARM Cortex M para la
programación de la plataforma EDU-CIAA NXP y el uso de los periféricos.
Se utilizaron buenas prácticas de programación de Lenguaje C para micro-
controladores y periféricos. Se escribieron comentarios en las declaraciones
de funciones. Se utilizaron constantes en mayúsculas, y además se utilizó el
formato camelCase para poner nombres significativos a funciones y varia-
bles. De esta forma, se obtuvo un código más modular, legible y reutilizable.
Mediante una FSM se implementó un sistema operativo tipo apropiativo
que se encarga de ejecutar de forma ordenada y secuencial los procesos que
lleva adelante el equipo. Además, se utilizaron otras máquinas de estado
para llevar a cabo las distintas funcionalidades del equipo.
Se diseñó, implementó y fabricó un poncho procesador de audio que inter-
conectado con la EDU-CIAA NXP conforma el hardware del equipo.
Se realizó la gestión del trabajo mediante un control de versiones, que re-
sultó fundamental para almacenar en todo momento del desarrollo una ver-
sión estable del trabajo.
Se realizaron test unitarios sobre las funciones complejas. De esta forma, se
probaron de forma aislada los filtros diseñados, el módulo de compresores
de audio y la adquisición y generación de audio reduciendo los tiempos de
desarrollo.
48 Capítulo 5. Conclusiones

Por lo tanto, se concluye que se cumplió con los objetivos planteados al principio
del trabajo. Se desarrollaron y probaron los principales módulos que componen
al equipo y se aplicaron los conocimientos aprendidos durante la Carrera de Es-
pecialización por parte del autor.

5.2. Próximos pasos

Para poder llevar este producto al mercado resulta imprescindible reconocer que
modificaciones y mejoras deben ser llevadas a cabo sobre el equipo. En la próxima
etapa del trabajo se debe hacer hincapié en los siguientes aspectos:
Diseñar, implementar y fabricar un PCB dedicado al equipo. Este PCB debe
poseer un DAC de audio, un ADC de audio y un display color para realizar
la configuración del equipo.
La adquisición de audio debe realizarse con una frecuencia de 96 kHz y 16
bit de resolución.
La generación de audio debe realizarse con una frecuencia de 96 kHz y 16
bit de resolución.
Analizar y seleccionar un circuito de reconstrucción de la señal analógica
para la señal de audio.
Se debe medir la distorsión armónica a la salida del equipo durante el pro-
cesamiento de audio.
 49

Bibliografía

[1] Audacity. Free, open source, cross-platform audio software. Disponible: Mayo
2000. URL: https://www.audacityteam.org.
[2] FEDERICO Bocco, FRANCISCO Giana y P Ramos. «Procesadores de
audio: filtros, generalidades». En: Departamento de ingeniería electrónica.
Catedra fundamentos de acústica y electroacústica. Universidad Tecnológica
Nacional, Argentina (2011).
[3] Oscar Bonello. «Procesado psicoacústico de audio para la transmisión de
alta calidad en FM Estéreo». En: ().
[4] Comisión Nacional de Comunicaciones CNC. Resolución N ◦ 142/96. 1996.
[5] L. Gilberto D. Fernández I. Sánchez. Compresores de audio. Disponible: junio
2011.
[6] Bruce Powel Douglass. Design patterns for embedded systems in C: an
embedded software engineering toolkit. Elsevier, 2010.
[7] F. Larosa. Patrones de diseño. UTN Haedo.
[8] Helenca Duxans Barrobés Marta Ruiz Costa-jussá. Diseño y análisis de filtros
en procesamiento de audio.
[9] MATLAB. R2019b. Disponible: 2019-03-20. URL:
https://la.mathworks.com/products/matlab.html.
[10] NXP. LPC435x/3x/2x/1x, Product data sheet. Disponible: 15 March 2016.
[11] Proyecto CIAA. Computadora Industrial Abierta Argentina. Disponible:
2016-06-25. 2014. URL:
http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start.
[12] Steven Smith. Digital signal processing: a practical guide for engineers and
scientists. Elsevier, 2013.
[13] Tomás RobiscoP. Los males del audio digital: Jitter, aliasing, errores de
cuantización. Disponible: Enero 2016. URL:
http://www.ispmusica.com/tecnologia-musical/didactica-estudio-de-
grabacion/1898-los-males-del-audio-digital-jitter-aliasing-errores-de-
cuantizacion.html.