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 :-)
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
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
