Enviando datos de audio en trozos usando comunicación por luz visible

Su enfoque general se ve bien, pero le faltan algunos elementos.

A menos que la luz recibida del LED por el fotodiodo sea mucho más potente que la luz ambiental, necesitará alguna forma de rechazarla. Normalmente, la luz ambiental será más potente que su LED.

Los LED de 850nm (cerca de IR) a menudo se usan específicamente porque no hay mucha luz solar cerca de esa longitud de onda. Luego, usaría un fotodiodo que coincida con la frecuencia de su LED.

El uso de un LED con un ángulo de haz estrecho concentrará la luz en un área más pequeña. Los ángulos más estrechos te darán un mayor flujo correspondiente para un vataje determinado, pero será más difícil apuntar al receptor.

Usar el LED y el fotodiodo adecuados ayudará mucho, pero es posible que no llegue hasta allí. Es posible que deba agregar un filtro de paso alto como parte de su amplificador de fotodiodo. La frecuencia de corte debe ser mucho mayor que 60Hz para evitar captar parpadeo de las bombillas.

Debe considerar qué frecuencia de muestreo y profundidad de bits desea para la transmisión de audio. Por ejemplo, el audio de 32Ksps de 16 bits tendría que transmitirse a 512kbps. Si estuviera usando un microcontrolador que pudiera ejecutar 32 millones de instrucciones por segundo, solo tendría 64 ciclos de instrucción para procesar cada bit. Es un presupuesto de tiempo bastante ajustado, ya que necesita hacer una conversión de ADC, posiblemente enviar cada bit varias veces como parte de algún esquema de modulación y administrar búferes.

El audio con calidad de teléfono tiene un ancho de banda de 3.4 kHz. Si se transmite a 8 bits por muestra, será necesario que transmita 27.2 kbps. En ese caso, el mismo microcontrolador de 32 MIPS tendría cerca de 1200 ciclos para procesar cada muestra, lo que es mucho más manejable.

Debe decidir si desea que la transmisión no tenga pérdidas o si está dispuesto a aceptar alguna pérdida. La sobrecarga adicional de la transmisión confirmada puede forzar una compensación que reduce su frecuencia de muestreo o la profundidad de bits para cumplir con la sincronización.

Realmente no necesitas comunicación bidireccional para enviar música. El éxito de la radio abierta lo demuestra. Solo aceptar unos pocos bits malos podría significar que de vez en cuando recibes una señal de estática del altavoz (de la misma manera que lo haces en la radio). El uso del esquema de codificación adecuado para los bits transmitidos (como delta-sigma o similar) reduciría los efectos de cualquier error de bit único.

Agregar la sobrecarga de paquetes para verificar que los datos son correctos requerirá más ciclos de reloj de la CPU para procesar las sumas de comprobación o CRC. El reconocimiento de paquetes podría llevar más tiempo mientras la CPU espera la respuesta. Se duplicaría el número de transmisores / receptores que necesita. Pero para todos sus aspectos negativos, al menos podría garantizar con una certeza muy alta que los datos eran correctos.

Debe considerar el efecto de la deriva del reloj entre las dos MCU. Por ejemplo, si su primer MCU envía un bit cada 100 ciclos de reloj y el segundo MCU muestrea un bit cada 100 ciclos y las frecuencias de los relojes son diferentes en un 1%, entonces cada 100 bits puede obtener un bit adicional (o perder un poco) . Un UART es una forma común de sincronizar la temporización al enviar bytes entre dos sistemas. Otros métodos, como la modulación delta sigma (mencionada anteriormente) son tolerantes a errores de un solo bit.

Lo que se describe es el almacenamiento en búfer de los datos de audio durante varios segundos para cubrir las interrupciones en la transmisión.

Esta es una práctica común en casi todos los servicios de transmisión de audio y video que encontrará en Internet, etc., y es por eso que hay una demora entre las señales de transmisión en vivo y de transmisión.

Sin embargo, para hacer eso es posible que necesite una comunicación bidireccional.

Es decir, de alguna manera, el lado transmisor necesita saber que el receptor ha detectado correctamente el paquete anterior antes de poder enviar el siguiente. Si el receptor informa de un error o no responde, el transmisor continúa enviando el mismo paquete hasta que lo haga, o hasta que se agote. Si no lo hace, por supuesto tendrá orificios molestos en el sonido.

Cuando las cosas funcionan bien, el transmisor / receptor transferirá los datos casi en tiempo real, pero el receptor se mantendrá en reproducción durante varios segundos, por lo que habrá un búfer de tiempo para permitir la interrupción intermitente ocasional de las comunicaciones. Dado que la velocidad de comunicación es más rápida que la velocidad de reproducción, una vez que se restablecen las comunicaciones, el búfer se rellena rápidamente.

Aparte de eso, el resto de tu esquema es bastante clásico.

Sin embargo, la señal luminosa debe enviarse como una portadora modulada, no solo en apagado. De esa manera, el receptor puede extraer selectivamente la luz de señal de cualquier otra luz de fondo u otras fuentes.

EDITAR:

Como señala Immibus, creo que hay otra forma de finalización única.

El transmisor puede dividir su búfer en, por ejemplo, 15 trozos de un segundo cada uno con un número de secuencia o marca de tiempo y luego enviar el búfer completo como un paquete. Luego, recolecta otro segundo de sonido y lo agrega al final del búfer FIFO, (deshaciéndose de la porción 15S) envía todo, repítelo. De esa manera, cada parte se envía en cantidad de veces.

Luego, el receptor mantiene su propio búfer de fragmentos rellenos de esos paquetes.

Cuando recibe con éxito el siguiente paquete del remitente, pega los fragmentos en las ubicaciones adecuadas en el búfer según el número de secuencia del fragmento o la marca de tiempo, básicamente uniendo los datos de nuevo en la secuencia de tiempo correcta.

Sin embargo, este método requiere un mayor ancho de banda.