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.
Ich würde mir eher überlegen ob du die vollen 10bit brauchst. Für Langzeitaufzeichnungen und Auswertung dürfte eine SD-Karte sinvoller sein.
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.
Zwischen einem RAM/EEPROM und einer SD Karte liegen die Atmel Datenflash. zB ein AT45DB161B mit 2MegaBytes fuer 1.70 Euro.
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.
Es gibt auch SPI-SRAM: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2698 avr
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.
Matthias Keller schrieb: > nimm eine SD-Card, wenn du so unter Platzmangel leidest ... Darauf wir es wohl hinauslaufen Danke für die Tipps
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-Code M. 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.