Bei der Komprimierung geht es darum, die Redundanzen in den Daten zu finden und zu entfernen. Da Sie uns anscheinend nicht viel über Ihre tatsächlichen Datensätze erzählen können, muss diese Antwort sehr allgemein gehalten sein.

Ich stelle fest, dass "Potentiostat" -Daten kontinuierlich sind, im Allgemeinen langsam variieren, aber von Probe zu Probe geringfügige Abweichungen aufweisen können. Eine gute Möglichkeit, dies in 15-Minuten-Blöcken (450 Stichproben) zu codieren, besteht darin, ein Polynom erster Ordnung (oder mehr, je nach allgemeiner Art Ihrer Daten) anzupassen zu dem Datenblock, um seine Gesamtform zu erfassen. ^{1 sup>}

Der Block würde dann als Parameter für dieses Polynom (möglicherweise vier 16-Bit-Zahlen) plus die einzelnen Stichprobenabweichungen von diesem Polynom codiert, bei denen es sich vermutlich um viel kleinere Zahlen handeln kann - möglicherweise 450 3- oder 4-Bit-Zahlen für insgesamt 1414 oder 1864 Bit anstelle der ursprünglichen 7200 Bit - ein Komprimierungsverhältnis von ungefähr 4 oder 5 zu 1.

Wenn Sie feststellen, dass Sie für die Beispieldeltas keine feste Breite verwenden können, sollten Sie die Huffman-Codierung verwenden, um sie darzustellen. Kleine Werte erhalten Kurzcodes, während die vermutlich selteneren großen Werte längere Codes erhalten . Abhängig von Ihren Daten sollten Sie immer noch in der Lage sein, ein Komprimierungsverhältnis von 3 zu 1 zu erhalten.

^{1 sup> Wenn sich herausstellt, dass die Daten eine zyklische Komponente haben, kann es sinnvoller sein, die wichtigsten periodischen Komponenten (Frequenz, Phase und Amplitude) mithilfe der Autoregression oder Fourier-Analyse zu identifizieren Notieren Sie die einzelnen Probendeltas aus der durch diese Parameter definierten Funktion.}

Ihre Daten bestehen wahrscheinlich aus zwei Komponenten:

• Niedrige Geschwindigkeitsänderungen der tatsächlichen Spannung
• Zufällige Abweichung aufgrund von ADC-Rauschen

Es ist wahrscheinlich, dass die zufällige Variation den größten Teil der Entropie in den Daten darstellt. Sie können es durch Oversampling reduzieren: Wenn Sie beispielsweise 4 Samples gleichzeitig nehmen und das Ergebnis durch 4 teilen, wird das Rauschen halbiert.

Es gibt kein weit verbreitetes Komprimierungsformat für die verlustfreie Komprimierung von ADC-Samples. Free Lossless Audio Codec wird manchmal verwendet, ist jedoch recht rechenintensiv und möglicherweise nicht für Ihr System geeignet. Generische verlustfreie Komprimierungsformate wie DEFLATE und LZ4 benötigen weniger Rechenressourcen, aber das Komprimierungsverhältnis ist nur dann sehr gut, wenn Sie benutzerdefinierte Vorverarbeitungsschritte hinzufügen. Daher ist es möglicherweise am besten, ein benutzerdefiniertes Komprimierungsschema zu entwerfen.

Die generische Struktur für Komprimierungsmethoden besteht normalerweise aus zwei Teilen:

1. Vorverarbeitung zur Verbesserung der Kompressibilität: Nehmen Sie beispielsweise die Differenz zweier aufeinanderfolgender Werte oder wenden Sie eine Polynomvorhersage an.
2. Entropiecodierung zur Darstellung jedes Symbols mit der geringsten Anzahl von benötigten Bits. Eine gängige Methode sind Huffman-Codes, bei denen entweder konstante oder dynamisch erstellte Tabellen verwendet werden.
ol>

Ein benutzerdefiniertes Format, das ich mit Erfolg verwendet habe, ist die Berechnung des Deltas zwischen aufeinanderfolgenden Samples und die Codierung der Differenz mithilfe der Elias-Gammakodierung. Es hat den Vorteil, dass es einfach zu implementieren ist und weniger als 1 Byte pro Abtastcodierung für sich langsam ändernde Signale erreicht.

Die beste Codierung hängt stark von der Verteilung Ihrer Samples ab. Sie haben uns gesagt, dass die Deltas größtenteils recht klein sind, was bedeutet, dass Ihr erster Schritt mit ziemlicher Sicherheit die Delta-Codierung sein wird (wobei jeder Wert in seine Differenz zum vorherigen Wert umgewandelt wird).

Eine weitere Einschränkung ist das System, auf dem Sie die Codierung durchführen. Sie haben gesagt, es ist "eingebettet", aber das umfasst eine ganze Reihe von Funktionen. Sie haben auch gesagt, dass SD-Karten außerhalb des Gültigkeitsbereichs liegen und dass Sie jeweils nur 450 Samples im RAM puffern, was auf ein sehr kleines System hindeutet. In diesem Fall erscheint eine Optimierung zur Vereinfachung und Erhaltung von CPU / RAM angebracht.

Wenn der häufigste Delta-Wert genau 0 ist - das heißt, viele Stichproben sind dieselben wie im vorherigen Beispiel -, ist es wahrscheinlich eine gute Idee, diese Läufe mit 0-Werten zuerst "in Lauflänge zu codieren". (Das heißt, nur speichern, wie viele in einer Reihe waren.)

Der Rest hängt weiter davon ab, wie die Werteverteilung aussieht. Ich werde aus Übungsgründen davon ausgehen, dass sie fast alle im Bereich von -64 < x < 63 (d. H. Eine 7-Bit-Ganzzahl mit Vorzeichen) liegen. Ich gehe auch davon aus, dass es am einfachsten ist, mit Bytes anstatt mit Bits zu arbeiten (was wahrscheinlich zutrifft, wenn Sie beispielsweise C schreiben). Wenn dies nicht zutrifft, finden Sie ein bitweises Schema ganz unten in der Antwort. Eine sehr einfache byteweise Codierung könnte ungefähr so ​​aussehen:

0b0xxxxxxx - Ein Literalwert (Delta), der im Teil "xxxxxxx" als 7-Bit-Ganzzahl mit Vorzeichen dargestellt wird. (Werte von -64 bis 63.)

0b10xxxxxx - eine Folge von Nullen (Deltas), deren Länge durch "xxxxxx" dargestellt wird (6 vorzeichenlose Bits können bis zu 63 ausdrücken, und wenn wir mehr benötigen, können wir einfach einen weiteren Eintrag hinzufügen.)

0b110xxxxx 0byyyyyyyy - Ein Literalwert (Delta), der im Teil "xxxxxyyyyyyyy" als 13-Bit-Ganzzahl mit Vorzeichen dargestellt wird.

0b11111111 0bxxxxxxxx 0byyyyyyyy - ein Literalwert (Delta), der als 16-Bit-Ganzzahl mit Vorzeichen dargestellt wird. Dies ist (offensichtlich) eine sehr ineffiziente Codierung, da ein 16-Bit-Wert in eine 3-Byte-Darstellung umgewandelt wird. Es verschwendet unnötig Speicherplatz, um die Ausgabebytes ausgerichtet zu halten. Dieses Schema ist nur dann sinnvoll, wenn so große Deltas sehr selten sind. (Jedes nichttriviale Komprimierungsschema hat einige Eingaben, für die die resultierende Ausgabe tatsächlich größer ist; dies ist ein Satz der Informationstheorie.)

(Das obige Schema ist leicht von der UTF-8-Codierung von Unicode inspiriert.)

Im Gegensatz zu Huffman-Codes (in einer anderen Antwort erwähnt) wird die angenommene Werteverteilung im Voraus festgelegt. Dies ist eine Tugend, weil es die Dinge einfach hält und es vermeidet, den Anfang jedes Probenblocks mit Overhead zu belasten. Dies ist ein Laster, da für ein adaptiveres Schema keine Handabstimmung der Verteilung erforderlich wäre.

Wenn Deltas üblich sind, die viel kleiner als -64 bis 63 sind, muss eine bessere byteweise Codierung als die oben genannte mehr als ein Sample gleichzeitig verarbeiten, um eine bessere Komprimierung als 2: 1 zu erzielen (d. h. mehr als ein Abtastwert pro Ausgangsbyte.)

Wenn die bitweise Codierung in Ordnung ist, lautet das viel einfacher zu beschreibende Schema wie folgt: Immer noch zuerst Delta-Codierung, dann Codierung wie folgt. Auf ein 0-Bit folgt eine positive Ganzzahl variabler Länge, die die Anzahl der folgenden Nullen codiert. Auf ein 1-Bit folgt ein Vorzeichenbit, dann eine positive Ganzzahl variabler Länge, die zusammen den nächsten (Delta) Wert codiert. Die positiven Ganzzahlen variabler Länge können mit einem der Codes von https://en.wikipedia.org/wiki/Universal_code_(data_compression) wie einem der Elias-Codes codiert werden. (Welche Codierung am besten ist, hängt wiederum von der Verteilung der Daten ab, aber wahrscheinlich ist jede davon großartig.)

Um Daves Idee zu erweitern, besteht eine andere Möglichkeit, einen 15-Minuten-Block zu speichern, wenn sich der Wert im Laufe der Zeit langsam ändert, darin, nur die Änderungen zu speichern.

Sie beginnen mit der vollständigen 16-Bit-Nummer und bestimmen dann, wie viele Bits Sie benötigen, um die größte Änderung zwischen zwei Abtastwerten zu speichern.Wenn beispielsweise die größte Änderung von 1050 auf 1013 erfolgt, beträgt die Differenz -37 oder 1011011 in der Zweierkompliment-Binärdatei.Dies erfordert 7 Bytes pro Abtastung anstelle von 16.

Schreiben Sie nicht alle zwei Sekunden Daten.

Schreiben Sie Daten nur, wenn die Änderung über einem bestimmten Schwellenwert liegt und einen Zeitstempel enthält.

Sowohl für Daten als auch für den Zeitstempel können Sie Deltas (Unterschied zum vorherigen Beispiel) mit weniger Bits protokollieren und nur dann die volle Breite verwenden, wenn die Änderung die für Deltas definierte Breite überschreitet.

Zwei Möglichkeiten:

1. Rollen Sie Ihr eigenes Komprimierungsschema.Fangen Sie einfach an: Wenn beispielsweise mehrere Proben nacheinander denselben Wert haben, verwenden Sie die RLL-Codierung.Die Verfeinerung des Systems kann Forschungs- und Entwicklungsanstrengungen erfordern.Die Antworten von Dave Tweed und Glenn Willen legen gute Ansätze nahe.

2. Wählen Sie ein vorhandenes Schema aus.Laut der Antwort von jpa fällt FLAC sofort ein (obwohl es auf Audio-Sampleraten abzielt).Wenn Sie über eine relativ leistungsfähige CPU verfügen und eine benutzerfreundliche Softwarebibliothek finden, können Sie Ihre Arbeit mit viel weniger Aufwand erledigen.

ol>

Wenn Sie nicht an Hochfrequenzrauschen interessiert sind, hilft ein Tiefpassfilter vor der Komprimierung wahrscheinlich dem Komprimierungsverhältnis in beide Richtungen.