Tienes un buen conjunto de circunstancias aquí; deberías poder alcanzar tu objetivo sin demasiados problemas. No veo nada en su descripción que elimine toda una clase de modulación (por ejemplo, modulación por cambio de fase , modulación por cambio de frecuencia , etc.). Algunos de los factores que intervendrían en la elección de un formato adecuado incluirían:
- La eficiencia espectral requerida (es decir, cuánto rendimiento de datos necesita en relación con el ancho de banda disponible)
- Los requisitos de complejidad para su receptor (que generalmente es la parte más complicada del sistema)
- Cuánto esfuerzo estás dispuesto a poner en el desarrollo de la implementación.
- Otras circunstancias específicas de su aplicación (por ejemplo, si tiene una precisión de sincronización baja en uno o ambos extremos, interferencia conocida o una respuesta deficiente del canal)
Entonces, marcando estos uno por uno para su sistema, podemos llegar a algunas pautas:
Parece que su mayor restricción es la respuesta de su canal (que está limitado por el DAC de su tarjeta de sonido). Si tiene 40 kHz de ancho de banda unilateral disponible, entonces estará limitado a una velocidad de símbolos que está algo por debajo de eso. Para una velocidad de datos objetivo de al menos 40 kilobits por segundo, querrás un esquema que transmita múltiples bits por símbolo.
Siempre que su plataforma integrada no esté cargada con demasiadas funciones, un procesador ARM moderno de 120 MHz debería ser capaz de manejar fácilmente la demodulación de casi cualquier formato en el rango de decenas de kilobits por segundo.
No estoy seguro específicamente con qué modelo está ejecutando, pero muchos procesadores recientes proporcionan una integración muy estrecha de los ADC integrados con el subsistema de memoria e interrupción, lo que quizás le permita (sin intervención manual de la CPU) muestrear automáticamente la señal de entrada en un determinado velocidad, almacene las muestras en la memoria interna y active una interrupción del procesador solo cuando un bloque de muestras de cierto tamaño esté disponible para ser procesado. Sé que algunos dispositivos Atmel como mínimo proporcionan este tipo de funcionalidad; He tenido buen éxito con ellos en el pasado.
EbN0
En cuanto a circunstancias especiales, para este sistema, no esperaría mucho de nada. Esperaría que la precisión del oscilador en el lado de la PC sea bastante buena (con un mínimo de control de cristal , por lo que está en el rango de <50 ppm más o menos; posiblemente mucho mejor si el oscilador está calibrado utilizando alguna otra fuente más precisa) ) Es probable que el lado incrustado sea el mismo; Supongo que está utilizando un oscilador de cristal como fuente de reloj. Dado que los dos extremos están cableados, supondré que no tiene interferencia notable.
Entonces, juntando todo esto en una sola recomendación, probablemente comenzaría por el camino de un enfoque de codificación de cambio de fase en cuadratura (QPSK) a 24 kilosímbolos por segundo . A 2 bits por símbolo, esto produce una velocidad de datos de 48 kilobits por segundo, que excede sus requisitos. Esta tasa particular hace que su implementación sea un poco más fácil; Dado que el DAC de salida se ejecuta a 96 kHz, esto da como resultado 4 muestras por símbolo (siempre es más fácil ejecutar a un número entero de muestras por tiempo de símbolo). Probablemente trataría de diseñar el lado incrustado para que muestree a la misma velocidad de 96 kHz si es posible; Esto evita la necesidad de hacer un nuevo muestreo en el extremo más privado de recursos.
Para evitar cualquier problema con la muesca de CC que emplea el DAC de su tarjeta de sonido, puede modular la señal QPSK en una portadora a 24 kHz. Entonces, el espectro de la señal modulada tendría un valor nulo en CC, que se alinearía con su muesca. Es posible que la muesca termine no siendo un problema en absoluto (especialmente si realmente tiene solo unos pocos Hz de ancho como se sugiere). En ese caso, podría funcionar con un esquema aún más simple que simplemente funciona en la banda base, evitando por completo la modulación del operador.
QPSK es una buena opción debido a su simplicidad, tanto en el transmisor como en el receptor. En su SNR, podría lograr una mayor eficiencia espectral utilizando un esquema más complicado como la modulación de amplitud en cuadratura (QAM) , pero la propiedad de envolvente constante de las señales PSK es atractiva desde el punto de vista de la complejidad del receptor. Como nota, si realmente necesitara más bits por símbolo en el futuro, podría pasar a una constelación PSK de orden superior como 8 o 16 PSK. Sin embargo, estos son subóptimos desde el punto de vista del rendimiento de la tasa de error de bits en comparación con las constelaciones QAM.
En lo que respecta a la implementación de una biblioteca, no estoy al tanto de nada en lo que pueda ingresar e ir, especialmente para una plataforma integrada. Es probable que la implementación de su receptor esté vinculada en cierta medida con la interfaz de hardware. Es posible que pueda encontrar algunas implementaciones existentes para los diversos pasos necesarios para el demodulador, pero necesitará al menos modificar lo que podría encontrar para que funcione bien en su plataforma. El proyecto GNU Radio es un buen lugar para buscar si solo desea ver implementaciones en C ++ de muchas operaciones diferentes de procesamiento de señales de comunicaciones, e incluso podría proporcionar un marco útil para implementar el transmisor a bordo de su PC. Como resumen, los pasos de alto nivel que su receptor necesitaría hacer incluirían:
Esto puede sonar como un proceso complicado, pero construir un receptor práctico incluso para una situación simple como esta puede ser muy esclarecedor. Solo comente si hay algo más que haya dejado fuera.