Compresión de datos para una gran cantidad de datos binarios

Tienes alrededor de 1 Mbyte de datos para almacenar. La EEPROM es barata en el esquema de las cosas. La parte cara está esperando 20 minutos para capturar los datos. La respuesta obvia es aumentar la velocidad de transmisión.

A 115.2 kBaud, la transferencia tomaría 12 veces menos, o aproximadamente 2 minutos después de tener en cuenta la sobrecarga del protocolo. Entonces, arregle el firmware para utilizar una velocidad de transmisión razonable.

Por lo que puedo decir, los primeros bytes son una marca de fecha, y los campos restantes tienen valores que son algo similares entre los registros.

Hemos tenido que lidiar con el mismo problema al enviar datos a través de una conexión satelital costosa. Algunas formas en que redujimos la cantidad de bytes fueron:

Una marca de tiempo : en lugar de sellar la hora de cada registro, tenga una marca de tiempo para los datos para X número de registros. Usted sabe que su frecuencia de muestreo es fija, por lo que sabe cuáles serán los tiempos de los próximos registros. Lo hacemos cada X número de registros, en caso de que haya un error en el que no se haya guardado un registro o que el satélite haya perdido un paquete. por ejemplo

timestamp1,A1,B1,C1
timestamp2,A3,B2,C2
timestamp3,A3,B3,C3

se convierte en

timestamp1,A1,B1,C1,A2,B2,C2,A3,B3,C3

Deltas : si las mediciones no cambian mucho entre muestras, es posible que en su lugar se envíen las diferencias entre las mediciones. por ejemplo

timestamp1,A1,B1,C1,(A2-A1),(B2-B1),(C2-C1),(A3-A2),(B3-B2),(C3-C2)

Las diferencias pueden expresarse con menos bytes que los valores absolutos, ahorrando espacio. Por supuesto, es posible que una de las diferencias sea demasiado grande entonces. En este caso, es posible que haya datos dañados, pero esa es otra razón para limitar el número de registros antes de repetir el proceso con una nueva marca de tiempo y nuevos deltas.

Algo completamente diferente : en otro proyecto hicimos algo completamente diferente. En lugar de descargar los datos, adjuntamos un registrador de serie al puerto serie y conseguimos que el instrumento le enviara cada registro. La recuperación de los datos implicaba entonces extraer la tarjeta SD y guardar el archivo en el disco. También agregamos un botón para presionar antes de retirar el disco, para detener la escritura en la tarjeta mientras se retiraba.

¿Qué hay de ver el problema en un nivel superior?
Los datos que presenta son muy simples, parece difícil encontrar patrones que puedan usarse para minimizar los requisitos de almacenamiento / tránsito. Sería útil tener una vista de los datos de nivel superior y qué información se pretende recuperar (en lugar de qué binario está almacenado actualmente).

Por ejemplo, tuve un problema similar (instrumentación, cada 15 minutos, guardado en EEPROM, conexión lenta, etc.) y mi solución se aprobó al utilizar el contexto de los datos: si faltaban muestras a tiempo (mis datos tenían la marca de tiempo) Asumiría que todos los valores faltantes son los mismos que el último registrado antes de los faltantes.
Ese tipo de enfoque podría llevarlo a una liga diferente a la de simplemente comprimir datos a la LZW.

Según lo sugerido por geometrikal, extraiga la marca de tiempo y envíelo solo una vez y use la codificación delta. Luego agrupe los campos en aquellos que "siempre" tienen un delta cero, aquellos que típicamente tienen deltas muy pequeños (por ejemplo, magnitud menor que cuatro), aquellos que típicamente tienen deltas pequeños (por ejemplo, magnitud menor a 16), y los que son mas variable

Para el grupo delta cero "siempre", use una codificación de longitud de ejecución en el grupo codificado verticalmente / a través del tiempo (un recuento de 16 bits podría ser conveniente, aunque sería suficiente con 15 bits). Si las desviaciones en este grupo son típicamente singulares (por lo que dos deltas secuenciales serían no nulos e idénticos en magnitud y opuestos en signo), el valor predeterminado (posiblemente una constante dura, posiblemente transmitida al comienzo de cada conjunto de datos) el salto de grupo se debe asumir con la siguiente longitud de ejecución utilizando el valor predeterminado. Es decir, este grupo se codificaría opcional_starting_default_value, longitud de ejecución del valor predeterminado, excepcional_valor, longitud de ejecución del valor predeterminado (tenga en cuenta que uno puede tener una longitud de ejecución de cero si dos valores excepcionales ocurren adyacentes entre sí). Si las desviaciones vienen en ráfagas que son altamente variables, puede ser conveniente utilizar una longitud de ejecución para describir la longitud de la ráfaga, cuyo valor de longitud sería seguido por la secuencia de valores delta de variante. Si las desviaciones no son extremadamente raras o no es deseable que las condiciones excepcionales exploten la demanda de ancho de banda, la longitud de ejecución que codifica los campos individuales en lugar de todo el grupo de "siempre" cero delta probablemente sería más deseable.

Para los grupos delta pequeños y muy pequeños, puede usar una codificación Huffman de secuencias de los valores delta pequeños con un código de escape. El tamaño de la tabla y cada entrada en la tabla se puede ajustar cambiando la longitud de la secuencia. Por ejemplo, la muy pequeña tabla delta (-3 a 3) con una longitud de secuencia de cuatro tendría 32 entradas y el tamaño de cada entrada podría ser de 32 bits (puede haber un campo de longitud de cinco bits con hasta 27 bits para la codificación) ; con una longitud de secuencia de ocho, la tabla tendría 64 entradas y el tamaño de cada entrada podría ser de 64 bits. Alternativamente, puede usar la secuencia delta delta / código de escape para evitar por completo la necesidad de una tabla. Cualquier valor delta alto (correspondiente a los códigos de escape) podría enumerarse en forma no codificada después del valor codificado. (Si pretende utilizar LZW después de este paso de codificación, es probable que no haya mucho beneficio en la codificación de la secuencia de Huffman ya que LZW usa un paso de codificación de Huffman. Sería deseable mantener juntos los valores delta que varían poco, de modo que las sustituciones sean más comunes dado que no hay preocupación por el tamaño de la tabla. .)

Para los campos más variables, si se va a usar un pase LZW posterior, el uso de los valores delta probablemente sea lo suficientemente bueno. La codificación Huffman de estos campos puede requerir una tabla excesivamente grande.

Como anotó en su edición, cada campo debe ejecutarse siempre que sea práctico si está utilizando un pase LZW. (Los campos delta cero "siempre" se pueden agrupar para disminuir trivialmente el tamaño: un conteo de longitud de ejecución para todo el conjunto de datos cuando ninguno de los valores cambia versus un conteo de longitud de ejecución para cada campo, pero probablemente no una optimización que vale la pena.)