Bij compressie gaat het erom de overtolligheden in de gegevens te vinden en ze te verwijderen. Aangezien u ons niet veel over uw feitelijke datasets lijkt te kunnen vertellen, zal dit antwoord erg algemeen moeten zijn.

Ik begrijp dat "potentiostat" -gegevens continu zijn, in het algemeen langzaam variëren, maar kleine afwijkingen kunnen hebben van steekproef tot steekproef. Een goede manier om dit in blokken van 15 minuten (450 steekproeven) te coderen, is door een polynoom van de eerste, tweede of derde orde (of meer, afhankelijk van de algemene aard van uw gegevens) te passen naar het gegevensblok om de algehele vorm vast te leggen. ¹

Het blok zou dan worden gecodeerd als de parameters van dat polynoom (misschien vier 16-bit getallen), plus de individuele sample-afwijkingen van dat polynoom, die vermoedelijk veel kleinere getallen kunnen zijn - misschien 450 3- of 4-bit getallen , voor een totaal van 1414 of 1864 bits in plaats van de oorspronkelijke 7200 bits - een compressieverhouding van ongeveer 4 of 5 op 1.

Als je merkt dat je geen vaste breedte kunt gebruiken voor de voorbeelddelta's, overweeg dan om Huffman-codering te gebruiken om ze weer te geven - kleine waarden krijgen korte codes, terwijl de vermoedelijk zeldzamere grote waarden langere codes krijgen . U zou nog steeds in staat moeten zijn om een ​​compressieverhouding van ongeveer 3 op 1 te krijgen, afhankelijk van uw gegevens.

¹ Als blijkt dat de gegevens een cyclische component hebben, kan het handiger zijn om autoregressie of Fourier-analyse te gebruiken om de belangrijkste periodieke componenten (frequentie, fase en amplitude) te identificeren, en dan registreer de individuele voorbeelddelta's van de functie gedefinieerd door die parameters.

Uw gegevens zullen waarschijnlijk twee componenten bevatten:

• Veranderingen met lage snelheid van de werkelijke spanning
• Willekeurige variatie vanwege ADC-ruis

Het is waarschijnlijk dat de willekeurige variatie het grootste deel van de entropie in de gegevens vertoont. Je kunt het verminderen door overbemonstering: als je bijvoorbeeld 4 samples tegelijk neemt en het resultaat deelt door 4, wordt de ruis gehalveerd.

Er is geen alom populair compressieformaat voor verliesloze compressie van ADC-samples. Gratis Lossless Audio Codec wordt soms gebruikt, maar deze is behoorlijk rekenkundig zwaar en is mogelijk niet geschikt voor uw systeem. Algemene compressie-indelingen zonder verlies, zoals DEFLATE en LZ4, nemen minder rekenkracht in beslag, maar de compressieverhouding is niet erg goed tenzij u aangepaste voorbewerkingsstappen toevoegt. Het is dus misschien het beste om een ​​aangepast compressieschema te ontwerpen.

De algemene structuur voor compressiemethoden bestaat gewoonlijk uit twee delen:

1. Voorverwerking om de samendrukbaarheid te verbeteren: bijvoorbeeld het verschil nemen tussen twee opeenvolgende waarden of polynoomvoorspelling toepassen.
2. Entropiecodering om elk symbool weer te geven met het minste aantal bits dat nodig is. Een veelgebruikte methode is Huffman-codes, waarbij gebruik wordt gemaakt van constante of dynamisch opgebouwde tabellen.

Een aangepast formaat dat ik met succes heb gebruikt, is om de delta tussen opeenvolgende samples te berekenen en het verschil te coderen met Elias-gammacodering. Het heeft het voordeel dat het eenvoudig te implementeren is en minder dan 1 byte per sample codering bereikt voor langzaam veranderende signalen.

De beste codering die je kunt gebruiken, hangt sterk af van de distributie van je samples. U hebt ons verteld dat de delta's meestal vrij klein zijn, wat betekent dat uw eerste stap vrijwel zeker delta-codering zal zijn (elke waarde transformeren in een verschil met de vorige waarde.)

Een andere beperking is het systeem waarop je de codering uitvoert - je hebt gezegd dat het "ingebed" is, maar dat omvat een behoorlijk scala aan mogelijkheden. Je hebt ook gezegd dat SD-kaarten buiten bereik zijn, en dat je slechts 450 samples tegelijk in RAM buffert, wat inderdaad een heel klein systeem suggereert. In dat geval lijkt optimaliseren voor eenvoud en behoud van CPU / RAM in orde.

Als de meest voorkomende deltawaarde exact 0 is - dat wil zeggen, veel samples zijn hetzelfde als de vorige sample - is het waarschijnlijk een goed idee om die runs van 0 waarden eerst te "run-length coderen". (D.w.z. gewoon opslaan hoeveel er op een rij waren.)

De rest hangt verder af van hoe de verdeling van waarden eruitziet. Ik zal omwille van de oefening aannemen dat ze bijna allemaal in het bereik -64 < x < 63 liggen (d.w.z. een 7-bits geheel getal met teken). Ik neem ook aan dat het het gemakkelijkst is om met bytes te werken in plaats van met bits (wat waarschijnlijk waar is als je bijvoorbeeld C schrijft) - als dat niet waar is, kijk dan helemaal onderaan het antwoord voor een bit-wijs schema. Een heel eenvoudige byte-gewijze codering zou er ongeveer zo uit kunnen zien:

0b0xxxxxxx - een letterlijke waarde (delta) weergegeven als 7-bits geheel getal met teken in het "xxxxxxx" -gedeelte. (Waarden van -64 tot 63.)

0b10xxxxxx - een reeks nullen (delta's), waarvan de lengte wordt weergegeven door "xxxxxx" (6 bits ongetekend kunnen tot 63 uitdrukken, en als we meer nodig hebben, kunnen we gewoon nog een item toevoegen.)

0b110xxxxx 0byyyyyyyy - een letterlijke waarde (delta) weergegeven als een 13-bits geheel getal met teken in het gedeelte "xxxxxyyyyyyyyy".

0b11111111 0bxxxxxxxx 0byyyyyyyy - een letterlijke waarde (delta) weergegeven als een 16-bits geheel getal met teken. Dit is een erg inefficiënte codering (uiteraard) omdat het een 16-bits waarde omzet in een weergave van 3 bytes. Het verspilt onnodig ruimte om de output byte-uitgelijnd te houden. Deze regeling heeft alleen zin als zulke grote delta's zeer zeldzaam zijn. (Elk niet-triviaal compressieschema heeft een aantal inputs waarvan de resulterende output eigenlijk groter is; dit is een theorema van informatietheorie.)

(Het bovenstaande schema is enigszins geïnspireerd door de UTF-8-codering van Unicode.)

In tegenstelling tot Huffman-codes (vermeld in een ander antwoord), wordt de veronderstelde verdeling van waarden van tevoren vastgelegd. Dit is een deugd omdat het de zaken eenvoudig houdt, en het vermijdt dat overhead wordt toegevoegd aan het begin van elk blok samples; het is een ondeugd omdat een meer adaptief schema geen handmatige afstemming op de distributie vereist.

Als delta's veel kleiner dan -64 tot 63 vaak voorkomen, zal een betere byte-gewijs codering dan de bovenstaande meer dan één sample tegelijk moeten verwerken om beter te worden dan 2: 1 compressie (dat wil zeggen, meer dan één sample per outputbyte.)

Als bitsgewijze codering ok is, dan is een veel eenvoudiger te beschrijven schema als volgt: eerst nog delta-codering en daarna als volgt coderen. Een 0-bit wordt gevolgd door een positief geheel getal met variabele lengte dat het aantal te volgen nullen codeert; een 1 bit wordt gevolgd door een tekenbit en vervolgens een positief geheel getal met variabele lengte, die samen de volgende (delta) waarde coderen. De positieve gehele getallen met variabele lengte kunnen worden gecodeerd met een van de codes van https://en.wikipedia.org/wiki/Universal_code_(data_compression), zoals een van de Elias-codes. (Welke codering het beste is, hangt weer af van de distributie van de gegevens, maar waarschijnlijk zullen ze allemaal goed werken.)

Om Dave's idee uit te breiden, is een andere manier om een blok van 15 minuten op te slaan als de waarde langzaam verandert in de loop van de tijd, door alleen de wijzigingen op te slaan.

Je begint met het volledige 16-bits getal en bepaalt vervolgens hoeveel bits je nodig hebt om de grootste verandering tussen twee samples op te slaan.Als de grootste verandering bijvoorbeeld gaat van 1050 naar 1013, is het verschil -37 of 1011011 in het binaire complement van twee.Dat kost 7 bytes per sample in plaats van 16.

Schrijf niet elke twee seconden gegevens.

Schrijf alleen gegevens als de wijziging een bepaalde drempel overschrijdt en neem een tijdstempel op.

Voor zowel gegevens als tijdstempel kunt u delta's (verschil met het vorige voorbeeld) loggen met minder bits en alleen de volledige breedte gebruiken als de wijziging groter is dan de breedte die u voor delta's heeft gedefinieerd.

Twee manieren om het te doen:

1. Rol je eigen compressieschema.Begin eenvoudig: als bijvoorbeeld meerdere opeenvolgende monsters dezelfde waarde hebben, gebruik dan RLL-codering.Het verfijnen van de regeling kan onderzoek en ontwikkeling vergen.De antwoorden van Dave Tweed en Glenn Willen suggereren goede benaderingen.

2. Kies een bestaand schema.Per jpa's antwoord, FLAC komt onmiddellijk in me op (hoewel het gericht is op audiofragmentfrequenties).Als je een redelijk krachtige CPU hebt en een gemakkelijk te gebruiken softwarebibliotheek vindt, werk je met veel minder moeite.

Als je niet geïnteresseerd bent in hoogfrequente ruis, zal een laagdoorlaatfilter vóór compressie waarschijnlijk de compressieverhouding op beide manieren helpen.