El mejor método para enviar datos a través de un canal de audio mono

Estoy buscando una forma de enviar datos binarios a través de un canal de audio en un transmisor de video/audio. Esta será una función adicional para mi producto porque ya tiene una interfaz de audio. Espero poder alcanzar una velocidad de datos de aproximadamente 1 kbit/s como mínimo, pero más alta estaría bien. Los requisitos para cualquier protocolo de este tipo serían:

  • Alta inmunidad al ruido, por lo que una señal con algo de ruido e interferencia no causa problemas. Idealmente, los datos estarían libres de errores o marcados con errores, ya que los datos corruptos podrían causar muchos problemas. Las señales más débiles pueden introducir fluctuaciones y otras molestias en la señal, por lo que debería ser capaz de soportarlas.
  • Ser capaz de trabajar en un canal de audio con ancho de banda limitado (aproximadamente 8 kHz). Esto incluye limitaciones de velocidad de respuesta y fluctuaciones variables, incluso entre relojes o bytes.
  • Ser fácil de implementar, tanto en transmisión como en recepción, en un pequeño microcontrolador.

El protocolo solo necesita ser unidireccional ya que solo se enviarán datos. La razón por la que pregunto esto es porque he analizado muchas opciones posibles (FSK, PSK, modulación del ciclo de trabajo, Manchester, etc.) pero no tengo idea de cuál sería la mejor.

Lo que inmediatamente me viene a la mente es hacer lo mismo que un módem antiguo que funciona a 300 baudios (o alguna otra velocidad lenta). Algunas otras ideas incluyen el uso del mismo tipo de circuito/formato de audio que los antiguos sistemas de recuperación de almacenamiento basados ​​en cinta (piense en CLOAD/CSAVE).
Si su jitter es tan malo que transmitir a unos pocos cientos de baudios va a ser problemático, odiaría saber cómo sonará su audio.
Ignorando el lado del hardware de la inmunidad al ruido (blasfemia), alta inmunidad al ruido significa corrección de errores. Además de las comprobaciones de paridad de hardware y el equilibrio de CC, como con Manchester, puede incluir sumas de comprobación/CRC: goo.gl/RwDlt . Elegir uno puede necesitar otro tema!
@Nick T, piense en una línea telefónica. Es de bastante mala calidad. Se trata de la calidad que obtienes de los transmisores RC baratos, pero es suficiente para escuchar que tu hélice está funcionando o para escuchar los mensajes de voz de tu sistema OSD.
@tyblu, estaba considerando usar Hamming (7,4) más paridad para la corrección de errores, además de una suma de verificación CRC16 para todo el mensaje; el CRC16 se puede generar en aproximadamente 16 ciclos en mi procesador utilizando el generador CRC integrado.
@Thomas, las líneas telefónicas tienen prácticamente cero fluctuaciones. El audio debe tener un jitter muy bajo o sonará terrible . Si su ruta de datos tiene problemas de latencia, los paquetes deben retrasarse y resincronizarse para "eliminar la fluctuación" de la señal. Si uno no llega a tiempo, se tira. (Todo esto parece discutible para su aplicación, que suena analógico, lo que implica un jitter insignificante AFAIK)
@Nick T, el avión puede estar a distancias de muchos km (hasta 25 km en algunos casos) desde el receptor, lo que presenta un retraso de aproximadamente 8 us en algunos casos; y el PLL en algunos de los transmisores más baratos no es tan estable. Las líneas telefónicas no necesitan tener PLL, así que no sufras por esto.
Espera, ¿un avión? Así que esto es RF. Ahora estás en territorio de radioaficionado/RF; tienen un montón de trucos, y yo no sé ninguno de ellos.
@tyblu, menciono en mi pregunta original "Estoy buscando una forma de enviar datos binarios a través de un canal de audio en un transmisor de video/audio".
@Thomas O: ¿Hamming encima de un CRC? ¿Quieres decir debajo? El CRC debe estar en datos codificados por hamming; de lo contrario, está desperdiciando muchos bits sin ningún motivo. CRC en un nivel inferior haría inútil cualquier corrección de error por encima de él. (a menos que lo ignore, entonces el CRC es inútil)
@darron: el CRC es para el mensaje, luego el mensaje está codificado con hamming (8,4) (7,4 más paridad).
@Thomas O: Suena bien. Los chips inalámbricos con los que jugué tenían incorporadas capas de protocolo basadas en CRC sin cerebro. Tenía muchas ganas de mejorar mi rango con FEC, pero la implementación lo impidió.

Respuestas (2)

Creo que RQDQ tiene la idea correcta. El mejor método para enviar datos digitales a través de líneas de audio de ancho de banda restringido es un problema que ya se ha resuelto para los módems .

Los módems de 300 bit/s usaban modulación por desplazamiento de frecuencia de audio para enviar datos. En este sistema, el flujo de 1 y 0 en los datos de la computadora se traduce en sonidos que se pueden enviar fácilmente a las líneas telefónicas. En el sistema Bell 103, el módem de origen envía 0s al reproducir un tono de 1070 Hz y 1s a 1270 Hz, y el módem de respuesta coloca sus 0s en 2025 Hz y 1s en 2225 Hz. Estas frecuencias se eligieron cuidadosamente, están en el rango que sufre la mínima distorsión en el sistema telefónico y tampoco son armónicos entre sí.

En los sistemas de 1.200 bit/sy más rápidos, se utilizó modulación por cambio de fase . En este sistema, los dos tonos para cualquier lado de la conexión se envían a frecuencias similares a las de los sistemas de 300 bit/s, pero ligeramente desfasadas. ...

Con un canal de 8 KHz, consideraría el muy simple BELL 202 AFSK de 1200 baudios ampliamente utilizado para radio por paquetes. Tenga en cuenta que esto es diferente al PSK de 1200 baudios utilizado en el ancho de banda muy estrecho de los circuitos telefónicos de voz.

Luego colocaría un esquema de verificación basado en software además de esto. Eso va a ser un poco más complicado en un enlace unidireccional que en uno bidireccional donde puede usar reconocimientos y reenviar datos corruptos. Si puede descartar los paquetes malos y esperar los buenos, es mejor.

Puedo descartar paquetes o mensajes defectuosos. Son monolíticos que contienen una posición GPS, voltajes, corrientes, etc.
Dado que se trata de datos simples, ¿podría usar una variación en un filtro de Kalman para descartar datos incorrectos, ya sea por encima o en lugar de parte de la detección de errores? Esto evitaría que los paquetes corruptos causaran problemas y también cubriría los problemas de hardware: goo.gl/MlK5q .
Rechazar paquetes con una suma de verificación incorrecta será menos matemático y más rápido que un filtro kalman, la pregunta es qué quiere hacer con una interrupción: mantener los últimos valores de telemetría y atenuarlos, o dejar que siga estimando en función del rumbo y la velocidad. y gradualmente gris hacia fuera, o?
El mejor método para enviar datos a través de un canal de audio mono
RespuestasAquíPolítica de privacidad1y, 0v