Hallo, ich habe einen Datenlogger mit einem ATMega644p gebaut der Daten von Sensoren auf eine SD Karte speichert. Alles funktioniert soweit ganz gut (danke für die Unterstützung hier aus diesem Forum:-)). Die Sensoren liefern die Daten bisher im ASCII Format und ich schreibe sie so auf die SD-Card. Ich kann sie dann am PC leicht lesen und habe etwas Software zur Auswertung geschrieben. Nun sollen aber (zusätzlich) andere Sensoren angeschlossen werden, die ihre Daten als Binärwerte zum ATMega (über UART) senden. Nun könnte ich diese einfach in Strings umwandeln und so auf die Karte schreiben. Das würde aber die Datenmenge (unnütz) vergrößern (für einen 16Bit Messwert werden dann aus zwei Byte fünf) und wäre auch irgendwie "unelegant", schließlich braucht sie mein Auswertungsprogramm im PC am Ende auch wieder als Binärdaten. Ich müsste mir also ein Datenformat ausdenken. Es muß zwar nur von meiner Softwaren (im µC und im PC) gelesen und geschrieben werden aber ich würde es trotzdem gern so designen wie das " professionell " gemacht werden würde. Wie geht man an so etwas heran? Wie trennt man einzelne Datensätze? In einer Textdatei kann man das durch Zeilenumbrüche machen. Falls dann einmal ein Datensatz aus irgendeine Grund nicht richtig gemessen, übertragen oder gespeichert wurde, kann diesen einen Datensatz ignorieren und nach dem nächsten Zeilenumbruch weitermachen. Wenn ich einfach binärwerte hintereinander auf die Karte schreibe und es irgendwo einen Fehler gibt, käme ja alles was danach kommt "außer Tritt". Bin gespannt auf Euere Anregungen :-)
ich würd die Werte als ASCII speichern, mit Kommata/Semikolons als Trenner
Richtig bemerkt. Durch Redundanz kann man die Fehlerwahrscheinlichkeit verbessern. Die erste Frage in diesem Zusammenhang ist, ob die Datensaetze immer dieselben sind, resp man mit einer einzigen Recordstruktur durchkommt, oder ob mehrere Records unterschiedlich haeufig auftreten. Ob man als ASCII oder binaer abspeichert ist nochmals eine entscheidung. ASCII ist besser leserlich. Vernuenftigerweise implementiert man beide, und kann mit einer Boolean umschalten.
Also in vielen Dateiformaten werden zunächst einmal bestimmte "Felder" deklariert. Eine Datei beginnt demnach mit einem Header. Hier werden gewisse Sachen wie etwa Sensorname, Messfrequenz o.ä festgelegt. Ebenso sollte dort auch die Angabe der Anzahl an Messwerten stehen und wo die Startadressen der Werte (oder andere Sachen) sowie Größe vom Header selbst sein. Meist folgen an den Header dann die Daten. Das Format sollte dann so gewählt werden, dass wenig umgewandelt werden muss sofern man dann nicht direkt MB-Monster erhält. Edit: Einen wichtigen Punkt hab ich vergessen. Im Header sollte auch angegeben werden wie die Datei gespeichert wurden. Also entweder im Klartext, binär, BCD..etc
Vor allem am Anfang der Datei eine Kennzeichnung des Formats (Magic) und der Formatversion vorsehen. Text sollte bei den heutigen Größen von SD-Karten kein Problem sein.
Grundsätzlich gibt es vier Mittel: 1. Du legst die Abfolge der Daten auf dem Papier fest und schreibst das Programm so, das es diese Daten in eben dieser Abfolge schreibt und liest. 2. Du legst feste Grössen für die Daten fest; benötigst Du also keine Trennzeichen. 3. Du legst bestimmte Tags fest, welche die Daten inhaltlich kennzeichnen z.B. Zwei Messstellen A und B Also: "A:xxx.xxB:yyy.yy" 4. Du definierst ein Trennzeichen. Wobei 1. und 2. 3. 1. und 4. sinnvolle und ausreichende Kombinationen geben. Du kannst natürlich immer noch ein Mittel mehr nehmen, das dann eine Redundanz gibt >Wie trennt man einzelne Datensätze? In einer Textdatei kann man das >durch Zeilenumbrüche machen. Falls dann einmal ein Datensatz aus >irgendeine Grund nicht richtig gemessen, übertragen oder gespeichert >wurde, kann diesen einen Datensatz ignorieren und nach dem nächsten >Zeilenumbruch weitermachen. Das Trennzeichen wäre also festgelegt, aber nicht die absolute Länge der Daten oder deren Bedeutung oder Abfolge. >Wenn ich einfach binärwerte hintereinander auf die Karte schreibe und es >irgendwo einen Fehler gibt, käme ja alles was danach kommt "außer >Tritt". Hier ist weder Abfolge oder Länge, noch Bedeutung noch Trennzeichen festgelegt. Kein Wunder, das da was aus dem Tritt kommen kann.
Daten als Strings speichern ist gar nicht so schlecht, wenn man genügend Platz hat. So kann man die Datei per Texteditor lesen und editieren, was durchaus nützlich ist. Also alles andere als unelegant.
Nimm ASCII-Text / CSV. Das bischen Ersparnis in der Dateigröße für ein binäres Format kann ja nicht so schwer wiegen, eine 2GB SD-Karte kostet ja nix mehr... Und wenn doch, gzip o.ä. ist auch nicht soo kompliziert zu implementieren, und macht den ASCII-Overhead mehr als wieder wett.
'sokrates mit XML' - das hat was ;-) Wenn er sich dann noch Gedanken über Multiplattform und irgendeine Form von Inhaltsübersicht macht, damit der Texteditor beim Lesen von 2GB nicht den Rechner killt, das wäre wohl ultimativ. Gruß - Abdul
Hallo, ich bevorzuge für "lesbare" Daten auch csv. Kann man nitfalls in jedem Editor öffen, sonst in Excel/Calc einlesen oder, wie ich es gerade in Arbeit habe, mit ein paar Zeilen php o.ä. in eine MySQl-Datenbank tragen. Geht zwar prinzipiell mit anderen Formaten auch, aber warum soll ich mit das Leben unnötig schwer machen. PS: auf einen 16MBit Flash (2MByte) passen so 3 Wochen Daten mit Datum, Uhrzeit, Sensornummer, Temperatur, (Feuchte), (Luftdruck), Status. 6 Sensoren bis jetzt, 6x Temperatur, 4x Feuchte, 1x Luftdruck. Gespeichert wird alle 5 Minuten. Gruß aus Berlin Michael
Bitte 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.