mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Datenlogger: Zeitstempel wie speichern?


Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin grade am Überlegen mir einen kleinen Datenlogger zu bauen (mit 
einem Atmega88 oder 168), der so alle 5-10 Minuten die Messwerte eines 
BME280 (also Temperatur, Luftdruck und Luftfeuchtigkeit) speichern soll. 
Im Zuge dessen kam mir auch in den Sinn, wie ich die Zeit speichern 
soll. Da ich überlege als Speichermedium keine SD-Card zu nehmen sondern 
ein EEPROM-Baustein (hab hier noch einige 24LC1025er rumliegen) ist 
Speicherplatz etwas knapp. Ich könnte natürlich Tag, Monat, Jahr usw. 
als Byte-Werte speichern, um das dann herunter zu brechen auf die 
Sekunde "genau" bräuchte dann der Zeitstempel alleine schon 6 Byte 
Speicher. Ich könnte mir aber auch vorstellen, dass man einen 
Zeitstempel mit noch weniger Byte speichern kann, nur wie ist die Frage. 
Soll ich mir hier ein Referenzdatum überlegen und lediglich die Sekunden 
zählen?

Autor: nicht"Gast" (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
als unix timstamp. braucht nur 32 byte

Autor: nicht"Gast" (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bit, nicht byte

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> Soll ich mir hier ein Referenzdatum überlegen und lediglich die Sekunden
> zählen?

Wird in der restlichen Welt so gehandhabt. Die übliche Systemzeit in der 
Unix/Linux-Welt zählt Sekunden seit dem 1.1.1970 in einem 32-Bit-Wert.

Wie oft soll Dein Datenlogger ausgelesen werden? Vielleicht genügt ja 
sogar ein 16-Bit-Wert, damit kommst Du bei 1-Sekunden-Auflösung auf 18 
Stunden, aber ist diese Auflösung wirklich nötig?

Alternativ könntest Du nicht die absolute Zeit im Zeitstempel vermerken, 
sondern nur die Differenz zum vorhergehenden; da wird das Zeitintervall 
nicht so groß werden, daß 16-Bit-Werte nicht genügen.

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:

> so alle 5-10 Minuten
...
> Soll ich mir hier ein Referenzdatum überlegen und lediglich die Sekunden
> zählen?

Was willst du mit Sekunden bei einem Datenpunkt alle 5-10 Minuten?

Du kannst das Prinzip des UNIX-Timestamps nehmen und passend für deinen 
Anwendungsfall modifizieren. Das Original zählt Sekunden seit dem 
1.1.1970 und kommt mit 4 Byte pro Timestamp auf gut 68 Jahre, bevor die 
Zahl überläuft.

Wenn du minutenweise zählst und nur 3 statt 4 Byte verwendest, kommst du 
auf knapp 32 Jahre bis zum Überlauf.

Alternativ kannst du auch nur die Zeitdifferenz zum letzten Datensatz 
speichern. Dann mußt du natürlich zum Anfang einmal einen absoluten 
Zeitpunkt aufnehmen. 5 Minuten passen zwar nicht mehr in 1 Byte, aber du 
kannst deinen Datensatz ja als Bitfeld packen, mit z.B. 10 Bit für die 
Zeit.

Oder du machst die Messungen immer genau alle 5 Minuten, dann brauchst 
du gar keinen Timestamp zu speichern.

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Wie oft soll Dein Datenlogger ausgelesen werden?

Etwa ein mal in der Woche soll er ausgelesen werden. In der "Nacht" soll 
er nur alle 30 Minuten die Daten sichern, am Tage so 5 bis 10 Minuten.

Was will ich eigentlich genau machen?

Ich will die Umgebungsbedingungen in unserem Gewächshaus mit loggen. Am 
Tage scheint da fleißig die Sonne drauf, sofern kein Wölkchen da ist. In 
der Nacht stelle ich mir stabilere Verhältnisse vor. Daher will ich am 
Tage das Messintervall kürzer haben als in der Nacht. Die Triggerung, 
wann welches Intervall gilt, werde ich wohl mit einer Photodiode oder 
einem LDR realisieren (was meine Bastlerkiste halt so her gibt).
Die EEPROMs, die hier so rumfliegen, haben 1024 kBit Speicher. Alleine 
einer dürfte dafür schon reichen. Aktuell hatte ich mir vorgestellt, 
Temperatur, Luftdruck und Luftfeuchtigkeit als Floats zu sichern (12 
Bytes gesamt) und die Zeit als ingesamt, wie schon gesagt, 6 Bytes 
(Stunde, Minute usw. als uint8_t). Mit 18 Bytes sollte es bei einem 
Messintervall von 5 Minuten sogar für rund 10 Tage reichen:

Axel S. schrieb:
> Was willst du mit Sekunden bei einem Datenpunkt alle 5-10 Minuten?

Flexibilität...damit ich einfach weis wie es geht

: Bearbeitet durch User
Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> Ich will die Umgebungsbedingungen in unserem Gewächshaus mit loggen. Am
> Tage scheint da fleißig die Sonne drauf, sofern kein Wölkchen da ist. In
> der Nacht stelle ich mir stabilere Verhältnisse vor. Daher will ich am
> Tage das Messintervall kürzer haben als in der Nacht. Die Triggerung,
> wann welches Intervall gilt, werde ich wohl mit einer Photodiode oder
> einem LDR realisieren

Wenn du Timestamps an deine Meßpunkte hängen willst, dann brauchst du 
ohnehin eine Echtzeituhr. Da kannst du das auch gleich zeitgesteuert 
machen.

> Aktuell hatte ich mir vorgestellt,
> Temperatur, Luftdruck und Luftfeuchtigkeit als Floats zu sichern

Das finde ich reichlich übertrieben. Der Sensor hat jeweils 16 Bit 
Auflösung (plus ein paar Pseudobits nach Filterung). Und die Genauigkeit 
ist jeweils nochmal deutlich schlechter. Die Bits, die du da mehr 
speicherst, sind im wesentlichen Rauschen.

Unter diesen Umständen würde ich die Zeit als Unix-Timestamp 
speichern. Ganz einfach deswegen, weil das ein Standardformat ist.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
M. K. schrieb:
> Aktuell hatte ich mir vorgestellt, Temperatur, Luftdruck und
> Luftfeuchtigkeit als Floats zu sichern (12 Bytes gesamt)

Die Rohwerte Deines ADC dürften genügen, und der wird kaum 16 Bit 
Auflösung haben. Damit reduziert sich der Platzbedarf auf die Hälfte, 
und Du kannst problemlos noch einen 32-Bit-Zeitstempel im Unixformat 
dazupacken.

Damit kommst Du auf 10 Bytes pro Datensatz bei sekundengenauer 
Auflösung, und Du kannst einen kleineren µC einsetzen, weil Du keine 
Floatingpoint-Arithmetik brauchst. Die kann problemlos das PC-Programm 
anstellen, das die erfassten Daten schlussendlich auswertet.

Autor: Sebastian S. (amateur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brauchst Du wirklich "echte" Zeitpunkte?

Wenn Du sowieso regelmäßig an einen Rechner willst/musst, so kann sich 
der auch den Startpunkt, der Messung, merken.
Bei einem - dem Rechner - bekanntem Messrhythmus kann dieser auch 
selbstständig die Messwerte, ihrem Zeitpunkt zuordnen.
Soll der Logger die Messwerte asymmetrisch aufnehmen, so kann es auch 
nicht schaden, wenn bei der Gelegenheit (auslesen) auch gleich die Zeit 
aktualisiert wird. Somit weiß der Rechner auch welcher Messwert wann 
gemessen wurde bzw. wird.
Wird in sinnvollem Abstand (mehrere Minuten) gemessen, so sind auch, in 
normalem Rahmen, keine Abweichungen zwischen der "internen" Uhr und dem 
Rechner zu erwarten. Selbst Billigquarze halten sich daran.

Im Übrigen: Deine Annahme darüber, wann Temperaturschwankungen 
(Tag/Nacht) zu erwarten sind ist falsch. Eine Böe, die kommt während Du 
schläfst; ein kurzer oder längerer Schauer in der Nacht, hat eine viel 
stärkere Auswirkung, als eine Wolke, die das Sonnenlicht verdunkelt.

Autor: Achim S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm 4 Bytes Sekunden seit wann auch immer.

Und optimiere erst, wen. Es rund läuft und Du optimieren musst.

Überlege Dir, wie klein dein Gewinn wäre, selbst wenn Du es auf 0 Bytes 
schaffst.

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Wenn du Timestamps an deine Meßpunkte hängen willst, dann brauchst du
> ohnehin eine Echtzeituhr

DCF77 Uhr läuft ja auch mit drauf ;)

Axel S. schrieb:
> Das finde ich reichlich übertrieben. Der Sensor hat jeweils 16 Bit
> Auflösung (plus ein paar Pseudobits nach Filterung). Und die Genauigkeit
> ist jeweils nochmal deutlich schlechter. Die Bits, die du da mehr
> speicherst, sind im wesentlichen Rauschen.

Guter Einwand, im Moment bekomme ich die Werte vom BME280 als Floats, da 
muss ich dann noch mal schaun wie ich die Rohdaten bekomme. Das hab ich 
aktuell nicht auf dem Schirm.

Axel S. schrieb:
> Unter diesen Umständen würde ich die Zeit als Unix-Timestamp
> speichern. Ganz einfach deswegen, weil das ein Standardformat ist.

Ich denke auch, dass das das Sinnvollste ist. Daher werde ich es auch so 
machen.

Rufus Τ. F. schrieb:
> Die Rohwerte Deines ADC dürften genügen, und der wird kaum 16 Bit
> Auflösung haben. Damit reduziert sich der Platzbedarf auf die Hälfte,
> und Du kannst problemlos noch einen 32-Bit-Zeitstempel im Unixformat
> dazupacken.

Platzbedarf ist grade nicht das Problem aber der Vorschlag ist gut, 
werde ich so wahrscheinlich umsetzen. Muss mir den BME280 nochmal genau 
anschaun damit ichs wieder auf den Zeiger bekomme, wie ich an die 
Rohdaten komme.

Rufus Τ. F. schrieb:
> Damit kommst Du auf 10 Bytes pro Datensatz bei sekundengenauer
> Auflösung, und Du kannst einen kleineren µC einsetzen, weil Du keine
> Floatingpoint-Arithmetik brauchst. Die kann problemlos das PC-Programm
> anstellen, das die erfassten Daten schlussendlich auswertet.

Ein kleinerer uC wäre nicht das Problem, die Atmegas liegen hier auch 
noch gelangweilt rum. Aber vielleicht bekomme ich es in einen 
Attiny4313, die liegen nämlich direkt neben den Atmegas mit ähnlicher 
Motivation rum ;)

Sebastian S. schrieb:
> Brauchst Du wirklich "echte" Zeitpunkte?

Ich sags mal so: Es wäre schön. Du hast natürlich auch völlig recht, es 
würde wohl auch genügen, wenn ich mir den Startzeitpunkt merken würde 
und dann über das Messintervall mir die Zeiten bestimmen kann. Eine 
DCF77-Uhr habe ich aber schon vorhanden, da kann man auch direkt deren 
Zeit benutzen und wenns dann noch in ein standardisiertes Format geht, 
umso besser.

Sebastian S. schrieb:
> Im Übrigen: Deine Annahme darüber, wann Temperaturschwankungen
> (Tag/Nacht) zu erwarten sind ist falsch. Eine Böe, die kommt während Du
> schläfst; ein kurzer oder längerer Schauer in der Nacht, hat eine viel
> stärkere Auswirkung, als eine Wolke, die das Sonnenlicht verdunkelt.

Ah, das ist interessant. u.A. wegen solcher Begebenheiten möchte ich den 
Datenlogger installieren.

Achim S. schrieb:
> Überlege Dir, wie klein dein Gewinn wäre, selbst wenn Du es auf 0 Bytes
> schaffst.

Gewinn? Hm, ist ein Hobbyprojekt für ein Hobby um den eigenen 
Wissensdurst zu stillen. Gewinn, zumindest in monetärer Form, spielt 
hierbei überhaupt keine Rolle aber danke für den Denkansatz.

Vielen Dank für eure zahlreichen Anregungen und Tipps. Das hat mir sehr 
geholfen und wird in das Projekt sicher mit einfließen.

Autor: georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht dass ich es so machen würde, aber eine andere Möglichkeit wäre:

Du speichsert am Anfang einen Header mit den Parametern Startzeit, 
Intervall tags, Intervall nachts, und dann speicherst du garkeine 
Zeitinformation mehr - du kannst ja bei der Auswertung für jeden 
Datensatz die Zeit errechnen.

Georg

Autor: Achim S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> Gewinn, zumindest in monetärer Form, spielt hierbei überhaupt keine
> Rolle

Gewinn im Sinne von wie viel Datensätze mehr du speichern könntest.

Alles hat seinen Preis, in Form von Speicherplatz, Entwicklungsaufwand, 
...

Der direkte Ansatz kostet relativ wenig und erlaubt z.B 1000 Datensätze.

Selbst mit höchster Optimierung werde es nicht allein doppelt soviele. 
Da ist das Potential bei der messwertrepräsentierung viel höher.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und bei der DCF Uhrzeit nicht diese verwenden, denn die fehlenden 
Datensatze der Zeitumstellung und die Schaltsekunden sind nicht so nett.

Autor: Sebastian S. (amateur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn eine DCF77 erreichbar ist und der µP öfters mal synchronisiert 
wird, ist bei bekanntem Messraster, eine Zeitreferenz wirklich unnötig.
Wie eine - softwareunterstützte, genaue Zeit implementiert wird wurde 
hier im Forum schon mehrfach angesprochen. Bei DCF77 kannst Du sogar den 
externen Rechner "stellen". Etwas "Intelligenz ins Protokoll natürlich 
vorausgesetzt.

Übrigens: Wenn die Peripherie unbedingt wissen will, wie spät es ist, 
kannst Du ja die Zeit, nachträglich, ins Datenprotokoll einfügen.
Dazu musst Du sie aber nicht speichern sondern nur während der 
Übertragung berechnen. Die "Startzeit" sollte dazu ja im Speicher 
vorhanden sein, der Rest ist einfache Addition.

Um noch mal auf die "äußeren" Einflüsse zu kommen: Auch wenn ein 
Gewächshaus etwas größer als Dein Finger ist, feuchte ihn mal an und 
Blase kräftig drauf. Im Sommer kühlt das; im Winter wärmt man so die 
Finger.
Gerade im Sommer können Lüfte, die sich irgendwo aufgeheizt haben, sehr 
großen Einfluss auf die Temperatur in einem Gewächshaus haben, wenn sie 
denn mal vorbeischauen. Dieses Phänomen kommt vor allem in bebauten 
Gegenden recht häufig vor. Noch größer ist natürlich der kurzfristige 
Einfluss einer "Dusche".

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wem die Rechnerei mit Unix-Timestamps auf einem kleinen 8-Bitter zu blöd 
ist, der reduziert die Zeitauflösung auf 2 Sekunden und bekommt Datum 
und Uhrzeit als YY/MM/DD und HH/MM/SS-Halbe in jeweils 16 Bits. Siehe 
FAT Zeitstempel.

: Bearbeitet durch User
Autor: Pedant (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Die übliche Systemzeit in der
> Unix/Linux-Welt zählt Sekunden seit dem 1.1.1970 in einem 32-Bit-Wert.

Schon wieder so ein gefährliches Halbwissen. Wo steht das, dass es ein 
32-Bit Wert sei?
#include <stdio.h>
#include <time.h>

int main()
{
  printf("sizeof(time_t): %u\n", (unsigned int)sizeof(time_t));
}
$ ./a.out 
sizeof(time_t): 8

Wer heute noch Sekunden seit Epoch in einem 32-Bit-Wert zählen will, hat 
aus dem Y2K-Problem nichts, aber auch gar nichts gelernt!

Autor: Epoch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Epoch = 1.1.2000

Wenn der 32 Bit Zähler überläuft habe ich ganz andere Probleme ;-)

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pedant schrieb:
> Wer heute noch Sekunden seit Epoch in einem 32-Bit-Wert zählen will, hat
> aus dem Y2K-Problem nichts, aber auch gar nichts gelernt!

Oh richtig. Das war echt heftig... Überall Tote, Verletzte, 
Zombie-Horden, marodiernde Magnetfelder, Vulkanausbrüche, 
Überschwemmungen... oh wait...

siehe dazu auch:

https://xkcd.com/607/

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also der große Vorteil der UNIX-Zeit ist, dass man sich um solche Dinge 
wie Sommerzeit nicht kümmern muss. Man ließt aus dem DCF77-Signal den 
Offset zu UTC raus, und rechnet das in die 32-Bit um die Du dann einfach 
jede Sekunde per Timer hochzählen kannst.

Alle Formate in "lesbarer" Form haben halt die Probleme, dass Die die 
Komplexität auf allen Stellen gleich explodieren lassen. Du musst ja 
Sachen wie Schaltjahre oder Sommerzeit nicht nur in Deinem Gerät 
implementieren, sondern auch noch da, wo Du das verarbeitest. Und wenn 
Du mal einen Sensor außerhalb Europas hast, wird es wirklich 
kompliziert. Die UNIX-Zeit macht das alles viel einfacher.

Ach ja, den Anfang der Epoche kannst Du ja beliebig wählen, das ist nur 
ein Offset auf die Zahl, und es ist sinnvoll die Zahl ohne Vorzeichen zu 
verwenden.

: Bearbeitet durch User
Autor: Norbert Suter (norproz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn du platz sparen willst, dann hätte ich noch einen weiteren input:

speichere nur "interessante" stützpunkte ins log, sprich wenn sich ein 
messwert wesentlich ändert und lege dazu den relativ genauen 
(unix-sekunde oder ein anderes verfahren der vorredner) timestamp dazu 
ab.

was interessant ist, musst du halt bestimmen. ich könnte mir vorstellen, 
dass gemittelte werte über einen bestimmten zeitraum (30 sek, 1 
minute...) dann geschrieben werden, wenn sich der wert wesentlich vom 
vorherigen mittelwert des intervalles unterscheidet oder eine bestimmte 
zeitdauer der letzten bedingung 1 verstrichen ist.

so hättest du zwar keine äquidistante aufzeichnung, aber eine 
speichersparende und zugleich eine, welche auch allfällige langsame 
drifts (bei kleinen gradienten halt) erfassen kannst.

Autor: Mark W. (kram) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Idee waere, speicher gar keine Zeitstempel, das spart am meisten 
Platz. Oder vielleicht nur den ersten.
Sondern fuehre die Messungen zu genauen Zeitpunkten durch und stelle 
sicher, dass Du alle Messungen bekommst.

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann natürlich auch nur den ersten Zeitstempel abspeichern und dann 
im festen Zeitintervall die Werte stets speichern. Problem nur: Es kann 
auch mal passieren, dass das System keinen Saft hat (Batteriewechsel an 
der Solaranlage oder ähnliches) und dann muss ich mir hier was überlegen 
wie ich das abfangen will. Die Idee von Norbert ist auch sehr 
interessant, darüber habe ich auch schon mal nachgedacht und so ganz 
verworfen hab ich die Idee mit dem "Triggerlevel" noch nicht.

Autor: Norbert Suter (norproz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... um kurven auf verschiedene arten abzuspeichern machten sich ja 
andere leute auch schon gedanken, interessant ist hier folgendes 
dokument:

https://www.entsoe.eu/Documents/EDI/Library/deprec...

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pedant schrieb:
> Wer heute noch Sekunden seit Epoch in einem 32-Bit-Wert zählen will, hat
> aus dem Y2K-Problem nichts, aber auch gar nichts gelernt!

Ganz im Gegenteil: Der hat gelernt, dass er mit den daraus entstehenden 
Problemen später mal seine Rente aufbessern können wird.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.