Proyecto: receptor de radio fm

Introducción

El objetivo de nuestro proyecto fue diseñar un receptor de radio FM de bajo costo y fácil de usar.

Nuestro proyecto utiliza un circuito integrado de receptor FM para realizar las unidades de preprocesamiento que se necesitan antes de que se puedan escuchar las señales de audio deseadas. La frecuencia de radio es demasiado rápida para procesar con nuestro hardware disponible y el ATMega644. Hemos integrado una pantalla LCD para comunicarse con el usuario y un teclado para permitir al usuario interactuar con el receptor y cambiar estaciones. Nuestra idea de proyecto inicial era crear un receptor que pudiera almacenar audio, y más tarde diseñar una radio que pudiera crear una lista de reproducción de la estación de radio dada. La información del título de la canción se envía junto con la señal de audio modulada a través de un sistema denominado RBDS (Radio Broadcast Data System). Aunque no pudimos trabajar con la función RBDS, hemos incluido algunos de los componentes de fondo, hardware y software en la sección RBDS del Apéndice para que tal vez un grupo futuro pueda expandir nuestro proyecto para implementar una característica usando RBDS.

Diseño de alto nivel

Antecedentes

Las señales de radio FM (modulada en frecuencia) se transmiten en una frecuencia portadora dentro del rango de 87.5MHz a 108.0MHz. Cada estación está provista de 0,2MHz para emitir su señal (en los Estados Unidos), sin embargo, un máximo de .15MHz se utiliza típicamente para evitar la interferencia con los canales adyacentes. La señal entrante necesita primero ser desmodulada, lo que implica múltiples etapas incluyendo el amplificador de bajo ruido, el mezclador de frecuencia y otras unidades de procesamiento de señal FM de nivel de hardware. Utilizamos un Receptor de Radio FM Single Chip AIROHA AR1010 para realizar estas etapas de preprocesamiento para nosotros. Vale la pena mencionar en este momento que a veces nos referimos al receptor AR1010 FM y los documentos para el receptor AR1000 intercambiablemente. Ambos AR1010 y AR1000 son receptores de AIROHA. La única diferencia entre los dos es que el AR1000 admite RBDS mientras que el AR1010 no. No pudimos obtener un AR1000 que hubiera sido útil para los propósitos de nuestro proyecto, pero gran parte de la literatura de apoyo para nuestro diseño de receptor de FM se especifica para el AR1000.

Funcionabilidad:

Nuestro receptor de radio puede realizar las siguientes funciones:

Sintonice hacia arriba o hacia abajo una frecuencia

Escanear hacia arriba o hacia abajo para la siguiente estación con una señal fuerte

Configure hasta 3 emisoras favoritas que estarán disponibles más tarde para sintonizar rápidamente

Ajuste el umbral de exploración para captar estaciones más fuertes o más débiles

Como se mencionó, Estados Unidos separa las frecuencias por .2MHz (100.1, 100.3, 100.5 ect). Sin embargo, en otras regiones de la palabra, las estaciones pueden ser separadas por solamente .1MHz. Por lo tanto, para dar cabida a ambas posibilidades, decidimos permitir al usuario afinar hacia arriba o hacia abajo por incrementos de 0.1MHz.

                                  Keypad used to control radio.

El usuario controla el receptor a través del teclado mostrado en la figura a la derecha. Los botones se asignan a la funcionalidad de la siguiente manera:

1, Sintonice

2, Escanear hacia arriba

3, Aumentar el umbral de exploración

4, Sintonizar

5, escanear hacia abajo

6, Disminuir el umbral de exploración

9, Restablecer el umbral de exploración

0, Ir a la estación favorita de la tienda 1

F, Ir a la estación favorita de la tienda 2

E, Ir a la estación favorita 3

D, Establecer estación favorita

El resto de los botones no están conectados y al presionarlos no tendrá ningún efecto en el receptor. Para configurar una estación favorita, el usuario debe realizar los siguientes pasos:

Sintonice la emisora deseada

Pulse el botón Set (D)

Pulse uno de los botones favoritos (0, F o E) en el que se almacenará la emisora. Cualquier estación previamente almacenada en ese botón se sobrescribirá.

Arquitectura general

Nuestro diseño se puede dividir en cuatro subcomponentes principales: la comunicación con el receptor, el almacenamiento de estación favorito, el teclado y la pantalla LCD. Aunque no pudimos incorporar las características RBDS al producto final, también hemos incluido el trabajo que hemos hecho con los aspectos de hardware y software que soportarían esa funcionalidad adicional. Estos componentes y la comunicación entre ellos se muestran en el siguiente diagrama.

Logic diagram of receiver.

La señal de radio entrante se transfiere a través de la antena al receptor de radio FM AR1010. La placa de ruptura con el receptor luego procesa la señal, y de ahí extrae las salidas izquierda y derecha, que conectamos a una toma de audio. El usuario puede simplemente conectar un altavoz para escuchar la emisora. Sin embargo, se necesita algún tipo de amplificador. Sin ella, la salida no es lo suficientemente fuerte para ser escuchada a través de los auriculares, incluso con el receptor ajustado a volumen completo. Cualquier pulsación de botón desde el teclado se procesa por el microcontrolador, que enviará los controles correspondientes al receptor y el mensaje correspondiente a la pantalla LCD.

Diseño del programa / hardware

Software

Cada uno de los cuatro componentes de nuestro diseño tiene componentes de software: la comunicación con el Receptor FM AR1010, el botón de interpretación presiona desde el teclado, establece las estaciones favoritas en la memoria a largo plazo y muestra el mensaje en la pantalla LCD.

Receptor FM

Decidimos el protocolo I2C para comunicarnos con el AR1010. La razón principal por la que elegimos I2C sobre SPI fue que el código de ejemplo disponible en línea utilizó I2C. Además, la interfaz de 3 hilos utiliza 26 señales de reloj para realizar una función de escritura simple, lo que habría complicado el soporte de SPI en el ATmega644. Gran parte de nuestro código que involucraba la comunicación I2C con el receptor se modificó a partir del código de ejemplo AR1000 ATMega168 disponible en Sparkfun Electronics.

Nos topamos con dificultades significativas con la comunicación I2C con el AR1010, el principal problema fue que una bandera enviada desde el esclavo (AR1010) al maestro (Mega644) nunca fue enviada para señalar que la condición de inicio fue recibida, y por lo tanto el microcontrolador Se estaba quedando atascado en el estado de espera. Pasamos por muchos otros conjuntos de código de ejemplo, incluyendo el proporcionado por la solicitud de NKC Electronics y trató de crear un programa desde cero, incorporando información de la Guía de Programación y los ejemplos de código disponibles para el AR1010 / AR1000. Sin embargo, nuestro problema persistió hasta que regresamos a nuestro código de ejemplo original. Si bien todavía no estamos seguros de por qué exactamente el indicador STC no estaba siendo configurado para los otros códigos, hemos concluido que el intento inicial falló debido a errores de hardware, lo más probable es una falta de resistencias pull-up (discutido en la sección de hardware a continuación) Los datos y la línea de reloj, que fueron remediados en nuestro intento de encontrar una secuencia de comandos I2C que funcionaría para nuestro chip.

Los registros en el AR1010 necesitaban inicialmente ser inicializados antes de que cualquier comunicación pudiera seguir. Los valores para los registros fueron recomendados por la Guía de Programación, y determinamos que el Mega644 funcionando en 16MHz no requería ninguna modificación a estos valores. Una vez que el AR1010 señaló que los registros habían sido escritos, pudimos iniciar la comunicación.

Todas las funciones de I2C se proporcionaron en el código de ejemplo, y también se modelan de los protocolos TWI como se proporciona en la hoja de datos Mega644. El volumen del receptor se ajusta por defecto al máximo, y como esto aún resulta en una salida demasiado demasiado para ser oído en los auriculares, no sentimos la necesidad de ajustar el registro que determina el volumen.

El receptor permite un ajuste fácil y rápido a una frecuencia dada. El canal del receptor se almacena en el segundo registro. Elegimos almacenar la frecuencia actual de la estación en una variable global, ya que queríamos poder acceder a la estación que estábamos escuchando en otros aspectos del programa sin tener que leer el registro cada vez. La frecuencia siempre tendrá un mínimo de un decimal (en MHz) y estará entre 87.5MHz (875KHz) y 108MHz (1808KHz), por lo que el almacenamiento de la estación en KHz permite que el valor sea representado con un entero de 16 bits. El canal a escribir en el registro 2 que corresponde a la frecuencia dada se puede calcular de la siguiente manera:

Frecuencia de RF (en KHz) = 690 + CHAN

Esta función también fue proporcionada por la Guía de Programación. Una vez que se escribió el nuevo canal, se envió un mensaje a la pantalla LCD para notificar al usuario de la estación actualizada. La función de sintonización toma un valor simple de 1 o 0 para determinar si el sintonizador debe subir o no (0).

El código de ejemplo también proporcionó una función para permitir una afinación más dinámica. La función Tune Hi-Lo mira el RSSI (valor de registro que refleja la intensidad de la señal) para ayudarlo a ajustar la frecuencia. Al probar esta función, no notamos una diferencia significativa en la afinación, por lo que decidimos utilizar el método más directo como se describió anteriormente.

El algoritmo principal para la exploración se describe en la Guía de programación y se implementa en el código de ejemplo. Al igual que la función de sintonización, el receptor puede explorar hacia arriba o hacia abajo, dependiendo del parámetro de entrada. Además, la resistencia mínima de la estación de radio necesaria para que la exploración se detenga en esa frecuencia particular depende de un valor de umbral establecido en un registro. Modificamos el código para que el usuario pueda aumentar, disminuir o restablecer el umbral a su valor original. De esta manera, si el usuario decide que el receptor está saltando las emisoras que todavía son audibles, tal vez no es ideal, puede disminuir el umbral a través de la función changeThreshold.

Determinamos experimentalmente el mejor valor por defecto para el umbral intentando valores diferentes y realizando una exploración para determinar qué umbral detectó estaciones verdaderas en el área. Los resultados de esto se discuten más adelante en la sección Análisis de Sensibilidad del Receptor de FM.

Teclado

Nuestro programa, una vez hecho inicializando todos los componentes del proyecto, entra en un bucle que escanea el teclado para presionar los botones. Modelando el KeytestGCC644.c del Laboratorio 2, el código reconoce cuándo puede haber ocurrido un empuje y confirma el empuje a través de una máquina de estado. A continuación, procesa qué botón se ha presionado antes de ejecutar las funciones apropiadas para ese botón, como se describe en la sección de funcionalidad anterior.

Memoria de estación favorita

La mayoría de las radios permiten a los usuarios almacenar estaciones de radio favoritas a las que se puede acceder con un solo botón de empuje. Para admitir esta función, designamos los cuatro botones inferiores al almacenamiento de la memoria de la estación favorita. Los tres de la izquierda eran para almacenar las estaciones. Una bandera global determinó si una prensa indicaba o no que el usuario quería escuchar la emisora ​​actualmente almacenada, en lugar de establecer la estación. Esta bandera podría ser conmutada por el botón inferior derecho del teclado.

Las estaciones favoritas se almacenan en la EEPROM del Mega644. Optamos por usar la EEPROM para que cuando el microcontrolador se restablezca, o se encienda después de estar apagado (un uso razonable) las estaciones favoritas todavía se establecerá. La única manera de borrar las estaciones es con una reprogramación del microcontrolador. Escribimos las tres estaciones favoritas como tres palabras (la estación está en KHz por lo que necesita 16 bits) en lugares pares, ya que la memoria es un byte direccionable. Sin embargo, antes de almacenar las estaciones, comprobamos un byte designado (dirección 1 ya que la ubicación de memoria 0 de EEPROM no es completamente fiable) para asegurar que las ubicaciones de memoria de emisoras favoritas contenían valores significativos. En un re-programa, estos podrían ser fijados a cualquier valor, por lo que en este caso hemos inicializado todas las estaciones favoritas a 88.0MHz.

LCD

Todas las funciones que utilizamos para controlar la pantalla LCD se obtuvieron de la biblioteca LCD proporcionada en Lab 1. Para asegurar que el usuario esté informado en todo momento sobre lo que el receptor estaba haciendo, designamos la línea superior como uno de los siguientes mensajes:

LCD Inicializado: al restablecer, permite al usuario saber que todo está bien con la pantalla

Actualmente on : estás sintonizado a la estación de abajo

Still looking : el escaneo está todavía en proceso y no se ha establecido en una estación todavía

Establecer favorito: si presiona una de las teclas favoritas, se ajustará a la estación actual

Scan Thresh +: aumenta el umbral de exploración en 1

Thresh de exploración: disminuye el umbral de exploración en 1

Restablecer el umbral (establecer el umbral de exploración al valor original

Uh oh: se ha producido un error al recuperar o configurar una estación favorita de la memoria, este mensaje se puede incorporar en otros aspectos de depuración del programa, así

La segunda línea de la pantalla LCD muestra la estación actualmente configurada. Cada vez que se llama a la función de sintonía (señalando que el receptor está en una nueva frecuencia), la línea inferior de la pantalla LCD se actualiza. Algunos ejemplos de las pantallas LCD se muestran a la derecha.

Harware:

Tres de nuestros componentes requieren hardware: el receptor de radio FM AR1010, la pantalla LCD y el teclado. Cada uno de estos componentes principales tiene su propio hardware correspondiente. Las conexiones para el LCD y el teclado fueron modeladas de los esquemas en Lab 1 y Lab 2 respectivamente.

AR1010

El AR1010 necesita ser alimentado por una fuente de alimentación de 3V. Con el fin de crear esta fuente de alimentación, creamos un circuito de cambio de voltaje, que tomó nuestra fuente de alimentación de 5V y creó una fuente constante de 3V. Vea el convertidor 3V en el apéndice para el esquema. El cambiador de voltaje consiste en un transistor, que crea un voltaje constante de la tensión en la base - 0.7V. El voltaje en la base es creado por un trimpot de 10k ohmios. Por lo tanto, hemos ajustado la tensión procedente del trimpot hasta que fue de 3,7V y, por lo tanto, creó la fuente de alimentación de 3V.

El AR1010 habla con el Mega644 a través de una interfaz de dos hilos usando el protocolo I2C. Para que la interfaz de dos hilos funcione, los datos de conexión y las líneas de reloj deben estar conectados a las resistencias de pull-up. Utilizamos resistencias de 10k ohmios para las resistencias pull-up, como lo recomendó el esquema de configuración AR1010.

Finalmente, el AR1010 requiere una antena para recibir la señal de radio. NKC Electronics, los distribuidores que nos donaron con una muestra del chip AR1010 y la placa de desmontaje, recomendaron un alambre calibre 31 ", 22. Primero probamos unos 3 pies de alambre de laboratorio y funcionó perfectamente.

LCD y teclado

La pantalla LCD se configuró exactamente como en la descripción del laboratorio 1 de ECE 4760. Lo hemos conectado al puerto A de la placa STK500. Controlamos el contraste usando un trimpot de 10k Ohm.

El teclado se configuró exactamente como en la descripción de ECE 4760 lab 2. Lo hemos conectado al puerto D de la placa STK500.

Resultados

En general, con la excepción de nuestra implementación RBDS, tanto nuestro hardware como nuestros diseños de software funcionaron muy bien. Al final, nuestro receptor FM, LCD y teclado funcionaron exactamente como se había planeado. Analizamos la función general del receptor FM, la funcionalidad del umbral de sensibilidad del receptor FM, la evolución de nuestro diseño de receptor FM y la funcionalidad de nuestro diseño. Nuestra implementación RBDS, incluyendo sus fallas, está en el apéndice.

Análisis de funcionalidad del receptor FM

Al probar cada una de las funciones de nuestro receptor de FM no encontramos problemas. El teclado controla las funciones sin ningún problema y la pantalla LCD muestra correctamente los mensajes apropiados. La única función que requirió más pruebas fue la función de exploración y el efecto del umbral de sensibilidad.

Análisis de umbral de sensibilidad del receptor FM

Una de las consideraciones de diseño de software que probamos fue el efecto del umbral de sensibilidad sobre las estaciones que el receptor de FM fue capaz de captar. El umbral de sensibilidad era una variable de 7 bits, permitiendo ajustes que variaban de 0 a 127. La siguiente tabla muestra qué estaciones podríamos captar a diferentes umbrales:

Como era de esperar, el establecimiento del umbral de sensibilidad muy bajo permitió detectar más estaciones, pero el problema es que algunas de estas emisoras de radio no existían realmente. Las estaciones 100.3, 103.5 y 107.1 no son estaciones de radio reales en la zona de Ithaca, NY. Mientras que 92.8, 96.0 y 108.0 no son emisoras de radio reales, 92.7, 95.9, 96.1 y 107.9 existen y el receptor estaba realmente recogiendo esas estaciones. Además, al establecer el umbral demasiado alto no se detectaron estaciones.

Problemas de diseño del receptor FM

Durante nuestro desarrollo del receptor de FM encontramos muchos problemas. Estos problemas incluían tanto hardware como software. Cuando primero probamos el chip AR1010 con el código de ejemplo de Sparkfun, lo conectamos y nada sucedió. No hubo comunicación a través de la interfaz de dos hilos. Sin saber si se trataba de un problema de hardware o software, intentamos depurar ambos a la vez. En primer lugar, descubrimos que estábamos dando una fuente de alimentación de 5V, en lugar de la necesaria 3V. Esto llevó al desarrollo de nuestro cambiador de voltaje. A continuación, como se mencionó anteriormente en la sección del programa, vimos que no habíamos incluido las resistencias pull-up en las líneas I2C. Durante el proceso de estas correcciones de hardware, conseguimos quemar uno de nuestros chips AR1010. Esto fue causado cuando teníamos las resistencias pull-up accidentalmente conectadas como resistencias pull-down. Durante la depuración del hardware, también intentamos depurar el software. Una descripción completa de este problema se discutió anteriormente en la sección de software. De esto concluimos que nuestro problema no era con el código de ejemplo de Sparkfun, sino, en cambio, con la implementación del código.

Análisis de la funcionalidad

Nuestro diseño es muy funcional y utilizable por la mayoría de la gente. Nuestra pantalla LCD le dice al usuario qué estación están escuchando y qué funciones están realizando en ese momento. El único grupo de personas que posiblemente podría luchar con nuestro diseño son los discapacitados visuales. Nuestro diseño no tendrá ningún efecto en otros proyectos ya que no crea ninguna interferencia. La única consideración de la funcionalidad que se debe tener en cuenta es si una señal de radio FM se puede recibir en el área que está planeando usarla.

Conclusión

En general, nuestro proyecto no cumplió con nuestras expectativas iniciales. Nuestra idea original del proyecto era nuestro producto final con las características adicionales de exhibir el título de la canción en nuestro LCD y poder almacenar canciones y tener la reproducción. Nos dimos cuenta de que no teníamos suficiente tiempo para un proyecto de esta magnitud, así que eliminamos el almacenamiento y la reproducción de canciones y decidimos tener la capacidad de almacenar los nombres de las canciones y crear una lista de reproducción de la radio. Estas funciones se basaban en un decodificador de sistema de datos de emisión de radio (RBDS). Pero tuvimos que abandonar el almacenamiento de la función de título de la canción y la capacidad de mostrar el título de la canción porque nos quedamos sin tiempo. Conseguir que el receptor de FM funcione tomó demasiado tiempo y no tuvimos bastante tiempo de depurar los problemas que teníamos con el decodificador de RBDS. Por lo tanto, no pudimos implementar una función de lista de reproducción porque, sin el decodificador RBDS, no pudimos obtener el título de la canción de la señal de radio. No estoy seguro de cómo podríamos haber mejorado nuestro enfoque de nuestro proyecto. Si hubiéramos podido evitar los problemas iniciales de hardware al configurar nuestro receptor de FM, podríamos haber tenido tiempo suficiente para depurar el decodificador RBDS y hacerlo operativo.

El único estándar utilizado en nuestro proyecto es el estándar I2C para la interconexión de dos hilos. Nuestro receptor de FM afirmó ser capaz de I2C y encontramos que cumplía con la norma. Si no fuera por problemas de hardware iniciales, el código de ejemplo que nos dio Sparkfun habría funcionado con su implementación I2C.

En nuestra idea original del proyecto, la única consideración legal que teníamos era la infracción de derechos de autor, ya que estábamos permitiendo que la gente almacenara canciones. La gente posiblemente podría haber salvado permanentemente esas canciones y las ha distribuido ilegalmente. Pero una vez que cambiamos nuestra idea de proyecto a crear una lista de reproducción de la radio, eliminamos la única consideración legal que teníamos.

En todos los aspectos del desarrollo de este proyecto, seguimos el Código de Ética del IEEE. En primer lugar, en el desarrollo de nuestro código, damos crédito a cada contribuyente. Hemos citado no sólo el código de ejemplo que construimos, sino también los autores de otro código que inspiró nuestro diseño. Además de citar colaboradores, también nos abstuvimos de comentar su código, para evitar dañar falsamente su reputación. Además, cuando estábamos obteniendo el módulo receptor FM y el decodificador RBDS, éramos francos y honestos con lo que estábamos planeando usar las fichas. Explicamos que íbamos a usar las fichas para nuestro proyecto de diseño senior, incluiríamos sus nombres en nuestro informe de proyecto y no usaríamos las fichas comercialmente. Además, a través de nuestro proyecto, buscamos aportes de Bruce Land y los asistentes de la enseñanza de ECE 4760. Nos ayudaron a solucionar problemas que no sabíamos cómo arreglar y evitar descuidos en nuestros diseños. Con el fin de mejorar los conocimientos técnicos sobre todos los temas que estudiamos, incluyendo el AR1010, I2C y RBDS, publicamos este informe en línea en el sitio web de la ECE 4760. Esperamos que las personas que busquen información sobre los receptores de FM, la implementación de I2C y la implementación de RBDS puedan encontrar nuestro trabajo tanto como una guía para empezar como como un trampolín para desarrollos futuros.

Apéndice

Sistema de datos de radiodifusión (RBDS) - no incluido en el diseño final

Fondo

RBDS es un estándar utilizado en transmisiones de radio para transmitir otros datos junto con la canción. Estos otros datos incluyen las letras de llamada de la emisora ​​de radio emisora, el nombre de la canción que se está reproduciendo, el género de la canción, las advertencias meteorológicas y los anuncios. Fue publicado en 1998 por el Comité Nacional de Sistemas de Radio.

Funcionalidad

Un decodificador RBDS funciona recibiendo una señal de radio y luego decodificando la información RBDS que se está enviando con ella. Los datos RBDS consisten en 4 paquetes de datos que se envían continuamente con señales de radio. Cada uno de estos paquetes consiste en un identificador de grupo, que identifica qué información contiene este grupo y el mensaje de datos de 16 bits. Utilizando el identificador de grupo, puede traducir el mensaje de datos utilizando el juego de caracteres apropiado dado en el documento estándar RBDS.

Para nuestro proyecto, íbamos a usar la información del título de la canción del mensaje RBDS y mostrarla en la pantalla LCD. También vamos a permitir que el usuario cree una lista de reproducción de canciones en la radio al guardar los nombres de las canciones que el usuario ha indicado. Esta característica habría sido muy útil, ya que no pudimos encontrar ningún dispositivo que realizó esta función que no sea a través de los flujos de radio por Internet.

Diseño de Hardware

Nuestro decodificador RBDS fue un TDA7333N de STMicroelectronics. Vea el apéndice para esquema de circuito. Este chip requería una tensión de alimentación de 3V, tres tensiones de referencia de 2,65V, 1,65V y 0,65V, un oscilador de cristal externo, datos I2C y líneas de reloj, y la señal de radio. Utilizamos el mismo suministro de 3V del receptor de FM. Hemos creado las tensiones de referencia utilizando potenciómetros. La razón para el oscilador de cristal externo es que TDA7333N requirió una frecuencia de sistema específica de 8.55MHz o 8.664MHz. Para crear esta frecuencia, utilizamos una frecuencia externa de 16Mhz y luego ajustamos los valores PLL dentro del TDA7333N para crear la frecuencia deseada. Las líneas I2C son las mismas líneas de la AR

Diseño de software

Nuestra idea era utilizar el software para comprobar el grupo de RBDS que contiene la información del título de la canción y mostrar que a la pantalla LCD. Se trata de una comprobación simple, ya que el TDA7333N proporciona el número de identificador del grupo.

Nuestro software permitió que el Mega644 controlara el TDA7333N mediante el uso de una interfaz I2C de dos hilos. Vea el código TDA_I2C.c en el apéndice. ADVERTENCIA: EL CÓDIGO NO FUNCIONA. No nos dieron código de ejemplo para empezar y no pudimos encontrar ningún código escrito para este chip en cualquier lugar, así que todo el código para esto es nuestro. El código implementa las mismas funciones I2C que el código del receptor FM. Nuestro código aún no comprueba el grupo RBDS que contiene la información del título de la canción, ni muestra esta información en la pantalla LCD. La razón de esto es que necesitábamos averiguar qué grupo contenía la información del título de la canción, que requería comunicación a lo largo de la línea I2C entre el Mega644 y el TDA7333N. Esta comunicación I2C no funcionaba.

En este momento, el código es capaz de escribir en los registros de la TDA7333N, pero no somos capaces de leer de ellos. Cuando se da un comando de lectura, el ACK nunca es recibido por el Mega644. Una razón para esto es que el TDA7333N no sigue exactamente el estándar I2C de cómo leer los registros del esclavo. El protocolo I2C dice que primero se envía un comando de escritura para inicializar el registro al que va a leer, luego se envía el comando de lectura. El TDA7333N no funciona de esta manera. Para ello, sólo se da un comando de lectura, y los registros se leen en un orden específico. Debe leer todos los registros antes del registro deseado y, a continuación, puede detener la transacción después de haber leído el registro deseado. Creemos que esta discontinuidad entre el protocolo TDA7333N y I2C es lo que está causando nuestros problemas de comunicación

Conclusión

Se necesitaba más tiempo para implementar el decodificador RBDS. No pudimos resolver los problemas de comunicación entre el Mega644 y el TDA7333N y, por lo tanto, no pudimos recibir los datos RBDS.