Pakkaamisella pyritään etsimään tietojen redundanssit ja poistamaan ne. Koska et näytä pystyvän kertomaan meille paljon todellisista tietojoukoistasi, tämän vastauksen on oltava hyvin yleinen.

Katson, että "potentiostaatin" tiedot ovat jatkuvia, vaihtelevat yleensä hitaasti, mutta niillä voi olla pieniä poikkeamia näytteestä näytteeseen. Yksi hyvä tapa koodata tämä 15 minuutin (450 näyte) lohkossa olisi sovittaa ensimmäisen, toisen tai kolmannen asteen (tai enemmän, riippuen tietojesi yleisestä luonteesta) polynomi tietolohkoon sen muodon vangitsemiseksi. ¹

Lohko koodattaisiin sitten polynomin parametreiksi (ehkä neljä 16-bittistä numeroa), plus yksittäiset poikkeamat polynomista, joka oletettavasti voi olla paljon pienempi - ehkä 450 3- tai 4-bittinen luku , yhteensä 1414 tai 1864 bittiä alkuperäisten 7200 bittien sijaan - pakkaussuhde noin 4 tai 5: 1.

Jos huomaat, että et voi käyttää kiinteää leveyttä deltanäytteisiin, harkitse Huffman-koodausta niiden edustamiseksi - pienet arvot saavat lyhyitä koodeja, kun taas oletettavasti harvinaisemmat suuret arvot saavat pidemmät koodit . Sinun pitäisi silti pystyä saamaan pakkaussuhde noin 3: een 1: een, riippuen tiedoistasi.

¹ Jos osoittautuu, että tiedoissa on syklinen komponentti, voi olla hyödyllistä käyttää autoregressiota tai Fourier-analyysiä tunnistaaksesi tärkeimmät jaksolliset komponentit (taajuus, vaihe ja amplitudi) ja sitten nauhoita yksittäiset näyte deltat näiden parametrien määrittelemästä toiminnosta.

Tietoissasi on todennäköisesti kaksi komponenttia:

• Todellisen jännitteen pienet nopeudenmuutokset
• Satunnainen vaihtelu ADC-melun vuoksi

On todennäköistä, että satunnaisvaihtelu edustaa suurinta osaa tietojen entropiasta. Voit vähentää sitä ylinäytteellä: esimerkiksi ottamalla 4 näytettä kerrallaan ja jakamalla tulos 4: llä melua voidaan puolittaa.

ADC-näytteiden häviöttömälle pakkaukselle ei ole yleisesti suosittua pakkausmuotoa. Ilmaista häviötöntä audiokoodekkia käytetään joskus, mutta se on melko laskennallisesti raskas eikä välttämättä sovi järjestelmääsi. Yleiset häviöttömät pakkausmuodot, kuten DEFLATE ja LZ4, vievät vähemmän laskennallisia resursseja, mutta pakkaussuhde ei ole kovin hyvä, ellet lisää mukautettuja esikäsittelyvaiheita. Joten voi olla parasta suunnitella mukautettu pakkausohjelma.

Pakkausmenetelmien yleinen rakenne koostuu yleensä kahdesta osasta:

1. Esikäsittely puristettavuuden parantamiseksi: esimerkiksi kahden peräkkäisen arvon eron ottaminen tai polynomiennusteen käyttäminen.
2. Entropiakoodaus edustaa kutakin symbolia vähiten tarvittavia bittejä. Yksi yleinen menetelmä on Huffman-koodit, joissa käytetään joko vakio- tai dynaamisesti rakennettuja taulukoita.

Yksi onnistuneesti käyttämäni mukautettu muoto on laskea peräkkäisten näytteiden välinen delta ja koodata ero käyttämällä Elias-gammakoodausta. Sen etuna on, että se on helppo toteuttaa ja saavuttaa alle 1 tavua näytekoodausta kohti hitaasti vaihtuvia signaaleja varten.

Paras käytettävä koodaus riippuu paljon näytteiden jakautumisesta. Olet kertonut meille, että deltat ovat enimmäkseen melko pieniä, mikä tarkoittaa, että ensimmäinen vaihe on melkein varmasti delta-koodaus (jokainen arvo muunnetaan edellisen arvon eroksi).

Toinen rajoitus on järjestelmä, jolla koodaat - olet sanonut, että se on "upotettu", mutta se kattaa melko monenlaisen kyvyn. Olet sanonut myös, että SD-kortit ovat soveltamisalan ulkopuolella ja että puskuroit vain 450 näytettä kerrallaan RAM-muistissa, mikä viittaa todellakin hyvin pieneen järjestelmään. Tällöin optimointi yksinkertaisuuden ja suorittimen / RAM-muistin säilyttämisen puolesta näyttää olevan kunnossa.

Jos yleisin delta-arvo on täsmälleen 0 - ts. eränäytteet ovat samat kuin edellisessä näytteessä - on luultavasti hyvä ensin "koodata" nämä 0 arvon arvot. (Eli vain tallentaa, kuinka monta peräkkäistä oli.)

Loput riippuvat edelleen siitä, miltä arvojen jakauma näyttää. Oletan harjoituksen vuoksi, että ne ovat melkein kaikki alueella -64 < x < 63 (eli 7-bittinen allekirjoitettu kokonaisluku). Oletan myös, että on helpointa työskennellä tavuilla eikä biteillä (mikä on todennäköisesti totta, jos kirjoitat esimerkiksi C: tä) - jos se ei ole totta, katso vastauksen alareunasta hieman viisas kaavio. Hyvin yksinkertainen tavukohtainen koodaus voi näyttää tältä:

0b0xxxxxxx - kirjaimellinen arvo (delta), joka on esitetty 7-bittisenä allekirjoitettuna kokonaislukuna osassa "xxxxxxx". (Arvot välillä -64 - 63.)

0b10xxxxxx - nollajoukko (deltoja), joiden pituus on "xxxxxx" (6 bittiä allekirjoittamatta voi ilmaista jopa 63, ja jos tarvitsemme lisää, voimme vain lisätä uuden merkinnän.)

0b110xxxxx 0byyyyyyyy - kirjaimellinen arvo (delta), joka on esitetty 13-bittisenä allekirjoitettuna kokonaislukuna osassa "xxxxxyyyyyyyy".

0b11111111 0bxxxxxxxx 0byyyyyyyy - kirjaimellinen arvo (delta), joka on esitetty 16-bittisenä allekirjoitettuna kokonaislukuna. Tämä on erittäin tehoton koodaus (ilmeisesti), koska se muuttaa 16-bittisen arvon 3-tavuiseksi esitykseksi. Se tuhlaa tarpeettomasti tilaa pitääkseen tavun kohdistettuna. Tällä järjestelmällä on merkitystä vain, jos tämän suuret deltat ovat hyvin harvinaisia. (Jokaisessa ei-triviaalisessa pakkausmenetelmässä on joitain syötteitä, joiden tuloksena saatu tulos on itse asiassa suurempi; tämä on tietoteorian lause.)

(Yllä oleva kaavio on hieman innoittanut Unicoden UTF-8-koodausta.)

Toisin kuin Huffman-koodit (mainitaan toisessa vastauksessa), oletettu arvojakauma on vahvistettu etukäteen. Tämä on hyve, koska se pitää asiat yksinkertaisina ja välttää lisäkustannusten lisäämisen jokaisen näytelohkon alkuun; se on varapuheenjohtaja, koska mukautuvampi järjestelmä ei vaadi käsin viritystä jakelulle.

Jos yleisesti paljon pienemmät kuin -64 - 63 deltat ovat, yllä olevaa parempaa tavukohtaista koodausta on käsiteltävä useampi kuin yksi näyte kerrallaan, jotta pakkaus olisi parempi kuin 2: 1 (ts. useampi kuin yksi näyte tavua kohden.)

Jos bittikoodaus on kunnossa, paljon yksinkertaisempi kuvata malli on seuraava: silti delta-koodaus ensin, sitten koodaus seuraavasti. 0 bittiä seuraa vaihtelevan pituinen positiivinen kokonaisluku, joka koodaa seurattavien nollien lukumäärän; 1 bittiä seuraa merkkibitti, sitten vaihtelevan pituinen positiivinen kokonaisluku, joka koodaa yhdessä seuraavan (delta) arvon. Vaihtelevan pituiset positiiviset kokonaisluvut voidaan koodata käyttämällä yhtä koodista osoitteesta https://fi.wikipedia.org/wiki/Universal_code_(data_compression), kuten yhtä Elias-koodeista. (Mikä koodaus on paras, riippuu jälleen tietojen jakelusta, mutta luultavasti mikä tahansa niistä onnistuu hyvin.)

Laajentamalla Dave-ajatusta, toinen tapa tallentaa 15 minuutin kappale, jos arvo muuttuu hitaasti ajan myötä, on tallentaa vain muutokset.

Aloitat täydellä 16-bittisellä luvulla ja määrität sitten, kuinka monta bittiä sinun tarvitsee tallentaa suurin muutos kahden näytteen välillä.Esimerkiksi, jos suurin muutos on välillä 1050 arvoon 1013, ero on -37 tai 1011011 kahden binaarimuodossa.Se vie 7 tavua näytettä kohti 16: n sijaan.

Älä kirjoita tietoja kahden sekunnin välein.

Kirjoita tietoja vain, jos muutos ylittää tietyn kynnysarvon, ja sisällytä aikaleima

Sekä tietojen että aikaleiman kohdalla voit kirjata deltat (ero edelliseen otokseen) vähemmän biteillä ja käyttää koko leveyttä vain, jos muutos ylittää deltoille määritetyn leveyden.

Kaksi tapaa tehdä se:

1. Rullaa oma pakkausohjelma.Aloita yksinkertaisesti: jos esimerkiksi useilla peräkkäisillä näytteillä on sama arvo, käytä RLL-koodausta.Järjestelmän tarkentaminen voi viedä tutkimus- ja kehitystyötä.Dave Tweedin ja Glenn Willenin vastaukset viittaavat hyviin lähestymistapoihin.

2. Valitse olemassa oleva malli.JPA: n vastauksen mukaan FLAC tulee heti mieleen (vaikka se onkin tarkoitettu äänen näytteenottotaajuuteen).Jos sinulla on kohtuullisen tehokas CPU ja löydät helppokäyttöisen ohjelmistokirjaston, työ tehdään paljon vähemmän vaivalla.

Jos et ole kiinnostunut suurtaajuisesta kohinasta, alipäästösuodatin ennen pakkaamista todennäköisesti auttaa pakkaussuhdetta kumpaankin suuntaan.