Algoritmo para comprimir un flujo de datos ADC de 12 bits en un microcontrolador Cortex M0

¿Es esto realmente una aplicación de audio? ¿Podría reemplazar todo con una interfaz de audio dedicada que resolverá todos estos problemas por usted, o necesita el nivel de CC preciso? El estéreo de 96 ksps es bastante alcanzable.

No tiene muchos MIPS con los que trabajar, así que voy a proponer el siguiente esquema de codificación. Es una tasa de bits técnicamente variable, por lo que es mejor que espere que los transitorios sean raros. Funciona para muestras de hasta 15 bits.

• Realizar un seguimiento de la muestra anterior
• Restar la siguiente muestra de la muestra anterior, llamar al resultado D
• Examine los bits por encima de 7. O son todos unos, o todos ceros, o una combinación (lo que indica un cambio transitorio o grande).
• Para los casos de todos unos o todos ceros: enmascare los 7 bits inferiores, transmita al host.
• Para el caso transitorio: transmita el byte superior de la muestra (no D) con el bit superior establecido en "1", luego el byte inferior.
• Periódicamente (por ejemplo, cada 256 muestras), envíe la muestra completa de todos modos con el bit superior establecido en 1. Esto permite la recuperación de errores.

La reconstrucción es simple:

• si el bit superior de un byte es 0, extienda con signo los 7 bits restantes y agréguelos a la muestra anterior para obtener la siguiente muestra.
• si el bit superior es 1, enmascararlo, leer el siguiente byte y ensamblar el resultado en una palabra.

Hay algunos pasos "sencillos" que puede seguir para reducir la velocidad de transmisión necesaria:

1. ¿Realmente necesitas una resolución de 12 bits? Si puede sacrificar los 4 bits menos significativos (que podrían ser solo ruido), reduce el ancho de banda requerido en un 33% y ahorra algunas operaciones al mismo tiempo.

2. en qué cantidad la señal "generalmente" cambia entre 2 muestras sucesivas. Por ejemplo, si el 95% de las veces, la diferencia está solo en los 6 bits menos significativos, puede enviar:

• si la diferencia es inferior a 6 bits, la diferencia se codifica como un entero con signo en 7 bits (con un 1 como el bit más significativo (8vo)); si la diferencia es superior a 6 bits, envía el valor completamente nuevo en 2 bytes (por lo que habrá 4 ceros de encabezado en el byte más significativo, lo que facilita su identificación)

Finalmente, una cosa interesante que dijiste en los comentarios es que necesitas una tasa de muestreo tan alta porque quieres observar transitorios.

Por lo tanto, veo 2 soluciones, un poco más complicadas, pero que podrían reducir significativamente la velocidad en baudios necesaria para su aplicación específica:

3. Si solo necesita los transitorios: ¿por qué no "disparar" sobre ellos? Almacena todas sus medidas en un búfer rodante (usando DMA si puede). Luego, utiliza algún cálculo de software para definir un transitorio (por ejemplo, una diferencia mayor que X entre la medición N y N-N0). Si detecta uno, envía solo los valores alrededor de la medición N. Si sus transitorios son raros, su tasa de baudios requerida se vuelve realmente baja. NB: en esta versión, SOLO ve los transitorios, no el resto (puede o no satisfacer sus necesidades, si no, vea la solución 4)

4. Otra solución es no enviar muestreos con intervalos de tiempo regulares: aún muestrea a 100 kHz (almacenado en un búfer interno con DMA), pero solo transmite parte de los datos: cuando los datos cambian rápidamente, envía muchos datos, cuando va cambiando poco a poco, te mandan pocos. Por ejemplo :

• digamos que la última medida enviada es M[N0] (medida en el muestreo #N0, 12 bits)
• llamemos a N la medida actual (valor=M[N]. Si N-N0 == 16, entonces X, con los 12 bits menos significativos de X siendo M[N], y los 4 más significativos siendo N-N0- 1 = 15 = 0b1111
• de lo contrario, si abs(M[N]-M[N0]) > umbral: envió X (2 bytes), con M[N] para los 12 bits menos significativos y N-N0-1 para los 4 bits más significativos (es decir, el número de medidas que te saltaste)
• otra cosa: no enviar nada.

Entonces, básicamente, en el lado receptor, recibe el valor en la forma A[0:3].M[0:12], siendo A el número de muestras omitidas (entonces (A+1) sampling_period el tiempo desde la última muestra ) , y M el valor de esa muestra. Si su señal está cambiando lo suficientemente lento y los transitorios son raros, tendrá un promedio de A entre 14 y 15 (seamos conservadores y digamos 14), por lo que tiene una tasa de bits promedio de 2 canales 16 bits * 100000 Hz/15 = 213 kb / s: eso se hace fácilmente en un UART de 1 Mb/s

Si lo hace, tendrá una sobrecarga computacional significativa, debe asegurarse de que puede hacer todo a tiempo. Tendrá que revisar todos los datos varias veces, esto es del orden O(n). Porque obviamente no puede hacerlo sin revisar todos los datos al menos una vez y también necesita hacer algo con ellos. Tal vez pueda ahorrar algo de tiempo en la automatización del procedimiento de envío: puede hacer que un temporizador active las interrupciones regularmente y luego active la transmisión de los datos con DMA. Esto liberará algo de poder computacional. Si lo necesita, tal vez pueda manejarlo de la manera más simple y aún así hacerlo. (ni siquiera publicó MCU y la frecuencia en la que opera, al momento de escribir esto)

Puede tener un diccionario de compresión estático o dinámico (qué sustituye a qué). Si es estático, puede codificarlo en el extremo receptor para descomprimirlo. Si es dinámico, se necesitarán más cálculos en el lado de MCU para generarlo y también deberá transmitirlo como datos al lado receptor (PC), porque necesita decodificarlo.

Primero, haga una estimación de qué tipo de valores devuelve su ADC con más frecuencia. Tal vez quieras comprimir los bits más significativos. Tendrá que buscar algunos algoritmos específicos, pero creo que no hay forma de hacerlo sin renunciar a un poco de ancho de banda, porque lo que envía debe ser distinguible: ¿envía datos sin procesar reales o datos comprimidos o diccionario? Por ejemplo, puede codificar que cada 16 bytes enviará un byte que será un diccionario para los próximos 16 bytes (o más, pero luego su compresión podría empeorar debido a la variedad de datos). Lo que significa que su compresión debe ser lo suficientemente buena para superar esta sobrecarga y aun así aumentar la cantidad total de datos transmitidos.

Pero el paso número 1 siempre es estimar si hay algo en los datos para comprimir. Si espera que todos los valores posibles sean totalmente aleatorios todo el tiempo, no hay mucho que pueda hacer, entonces es posible que desee descartar algunas medidas. Esta es simplemente su limitación de hardware. Solo puedes obtener tanto con eso.

Haga su procesamiento en el ARM y envíe un resultado procesado

Solo necesita comunicaciones de ancho de banda completo con la PC si planea que el ARM sea solo un ADC USB tonto y todas las cosas inteligentes que suceden en la PC. Si coloca el procesamiento en el ARM, puede enviar cosas a la PC más lentamente.

Dices que estás buscando transitorios. Esencialmente, entonces estamos hablando de diferenciación (buscando una tasa de cambio rápida). Habiendo hecho esto recientemente con el trabajo (diferenciando la posición para dar velocidad y aceleración, y luego ejecutando el control de posición-velocidad-aceleración de circuito cerrado), puedo decirle que el muestreo es ruidoso y necesita niveles significativos de filtrado cuando busca a tasa de cambio. Si no lo hace, entonces los falsos disparadores del ruido van a matar su diseño. (Filtros de paso bajo Bessel FTW, debido a un sobreimpulso mínimo y un retraso de grupo sólido en la banda de paso; y también mire la transformada MZTi para obtener una mejor respuesta a medida que la constante de tiempo del filtro se acerca a Nyquist).

Ahora tenemos algo con más datos útiles para que funcione la PC. Pero también tenemos algo que se puede enviar de regreso a la PC más lentamente, porque si ha filtrado sus datos con un filtro de paso bajo, entonces no necesita enviar esos datos más rápido que el doble de su nuevo ancho de banda.