Hallo zusammen.
Ich möchte einen Datenlogger mit einem
Atmel-MC bauen. Eingelesen werden mehrere
Analogkanäle also 10Bit-Werte.
Damit ich möglichst viele Daten im
"begrenzten" Speicher (RAM o. EEPROM)
unterbringen kann, habe ich mir folgende
Strategie überlegt:
Von der ersten Messung speichere ich den
vollen 10Bit-Wert. Von den nachfolgenden
Messungen, werde ich nur den Differenzwert
zur Messung davor speichern. Der Sinn liegt
darin, dass die Differenzwerte kleiner als
10Bit sind. (Im Mittel rechne ich mit 4-5Bit + Vorzeichen).
Diese "kleinen" Zahlen möchte ich nun in
int- oder long-Variablen so zusammenfassen
"zippen", dass der Speicher des MC möglichst
optimal genutzt wird.
Das Suchen im Netz bringt unzählige
Links zum komprimieren von PC-Daten und so.
Ich suche aber nach einem Rechenverfahren
für mein oben beschriebenes Problem.
Wer kann mir ein Stichwort, Prozedur oder
anders Hilfreiche nennen?
Danke schon mal im Voraus.
Erstmal würde ich nicht 10Bit in shorts (16bit) Speichern, sondern immer
schön zusammenschieben. Also 16 Werte in 160Byte. Oder 8 Werte in
80Byte, ...
So bekommst du in einen 24c512 i2c eeprom schonmal 52428 Werte rein,
8bit bleiben übrig.
Mit deiner Differenzrechnung kommst du bei 10Bit erstwert, dann 6Bit
Differenz inkl. Vorzeichen auf 87379 Werte, die reinpassen...
Wenn das nicht reicht such dir z.B. eine einfach ZIP Implementierung,
die dir alle 25000 Werte oder so den Inhalt des eeproms komprimiert. Das
dürfte in ca. 15-20k Code passen und in ca. 3-5 Minuten durchgelaufen
sein.
Wenn das nicht reicht würd ich eine 2GB SD Karte für <5 Euro reinpacken.
Huffman-Codierung der Differenzen: kleine kurz, grosse lang codieren.
Einfachbeispiel:
0 = 0
10xxxx = 4 Bit
110xxxxxxx = 7 Bit
111xxxxxxxxxx = 10 Bit
Welche solche Variante optimal ist kannst du aus der
Wahrscheinlichkeitsverteilung einer Probemessung ermitteln und fest ins
Programm einbauen.
>die Atmel Datenflash
Dafür gibt es sogar ein schickes "Referenzdesign" mit Quellcodes dazu,
der AT90USBKey, bei dem könnte man abgucken.
Zweimal 8MB auf dem Board (AT45DB642D).
Oh weh A.K. Wenn doch Huffman nur so einfach wäre. Alleine das
Aufstellen des Baumes fordert einen sehr rechenintensiven und vor allem
durchdachten Algorithmus.
Martin Schwaikert schrieb:> Oh weh A.K. Wenn doch Huffman nur so einfach wäre. Alleine das> Aufstellen des Baumes fordert einen sehr rechenintensiven und vor allem> durchdachten Algorithmus.
Oh weh Martin: Das kann man vorher auf dem PC machen und fest ins
Programm einbauen. Ist dann nicht für jedes Signal optimal, aber dafür
sehr einfach im Controller.
Für geringere Ansprüche peilt man über den Daumen.
Grübler schrieb:> Wer kann mir ein Stichwort, Prozedur oder> anders Hilfreiche nennen?
Hallo,
schau mal nach ADPCM-Codierung damit hast du etwa 50% Speichereinsparung
wenn das Signal sich nicht allzu stark ändert.
Gruß Anja
Naja, also Huffman setzt das Wissen über die
Auftrittswahrscheinlichkeiten voraus. Klar kann man das auch grob
peilen. Wenn's allerdings dumm läuft, werden die Daten größer, und nicht
kleiner. Einfach abschätzen mag funktionieren, wenn man genau weiß, wie,
aber nicht, wenn man aboslut keine Ahnung hat. Ich denke, der TO wird
eher letzteres erfüllen.
@Dussel: Hilft RLE denn auch bei Nicht-magnetischen Speichern?
Es wäre im Allgemeinen sehr hilfreich, wenn wir wüssten, welche Daten zu
erwarten sind. Wenn oftmals gleiche Werte auftauchen, dann wäre eine Art
Huffman natürlich erste Wahl. Wenn die Werte eher Rauschen entsprechen,
dann wohl nur ein großer Speicher.
Anja schrieb:> schau mal nach ADPCM-Codierung damit hast du etwa 50% Speichereinsparung> wenn das Signal sich nicht allzu stark ändert.
ADPCM ist m.W. verlustbehaftet. Gut für bestimmte Audio-Anwendungen -
aber für eínen Datenlogger?
M. Schwaikert schrieb:> Naja, also Huffman setzt das Wissen über die> Auftrittswahrscheinlichkeiten voraus.
Das lässt sich doch herausfinden, sobald man genug Daten gesammelt hat.
http://de.wikipedia.org/wiki/Shannon-Fano-Kodierung#Huffman-CodeM. Schwaikert schrieb:> Wenn's allerdings dumm läuft, werden die Daten größer, und nicht> kleiner.
Dann kann man für den Datenblock ein Flag setzen und die Daten Roh
speichern.
M. Schwaikert schrieb:> Wenn die Werte eher Rauschen entsprechen,> dann wohl nur ein großer Speicher.
Wenn sich die Differenzen in 5-Bit unterbringen lassen, dann gibt es
(maximal) 32 Werte, die man bei Huffman codieren muß.
Ich würde mit 2 Blöcken im RAM arbeiten.
Während Block A mit 1024 Messwerten per IRQ gefüllt wird, wird Block B
versucht kleiner zu machen.
Gruß
Jobst
Normalerweise macht man das so:
0sxx = delta of 2 bit + sign.
10sx xxxx = delta of 5 bit + sign.
11xx xxxx xxxx = 10 bit data
Sign bit, 0=positive 1=negative
0100 sowie 1010 0000 ist illegal für Daten und werden somit als Marker
verwendet. 1010 0000 schaltet zwichen komprimierten Daten un
unkomprimierten
um, 0100 xxxx definiert irgendwas, z.B. könnte es sein dass 0100 fnnn
einen Kanal aktiviert oder deaktiviert. nnn = Kanal und f=flag,
1=aktive.
Wenn ein Kanal inaktiv ist, dann behält er immer den letzten Wert und
die
Logdaten werden übersprungen. Im Ram sollten mindestens 4
unkomprimierte Werte zwischengespeichert bevor sie geschrieben werden,
also 44 bytes
inkl 4x Bitfelder welche den Status der Kanäle speichern, Aktiv oder
nicht.
Chris schrieb:> 0100 sowie 1010 0000 ist illegal für Daten und werden somit als Marker> verwendet. 1010 0000 schaltet zwichen komprimierten Daten un> unkomprimierten um
Hmmm, ich würde 0100 für -4 und 10100000 für -32 durchaus zulassen.
Allerdings benötigt man 10ssssxx nicht. Dafür reicht 0sxx. 10ssssxx kann
also für andere Zwecke herhalten.
Wenn man nur Wertänderungen, jedoch keine zeitkontinuierliche Datenfolge
benötigt, kann 0000 auch entfallen.
Gruß
Jobst
M. Schwaikert schrieb:> Wenn die Werte eher Rauschen entsprechen,> dann wohl nur ein großer Speicher
Es kommt drauf an, ob das Rauschen Information darstellt oder einfach
per Vorverarbeitung in den Müll befördert werden kann.
Willi W. schrieb:> M. Schwaikert schrieb:>> Wenn die Werte eher Rauschen entsprechen,>> dann wohl nur ein großer Speicher>> Es kommt drauf an, ob das Rauschen Information darstellt oder einfach> per Vorverarbeitung in den Müll befördert werden kann.
Ja, wie gesagt. Wenn die Daten gleichverteilt sind, wird es schwieriger.
Es wäre daher einfach gut zu wissen, welche Daten zu erwarten sind. Das
sollte der TO mal mitteilen.
Martin Schwaikert schrieb:> Das sollte der TO mal mitteilen.
Hat er, wenn auch rudimentär: "Im Mittel rechne ich mit 4-5Bit +
Vorzeichen". Gleichverteilung klingt anders.
