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?
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.
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.
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
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.
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.
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.
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.
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.
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
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.
Und bei der DCF Uhrzeit nicht diese verwenden, denn die fehlenden Datensatze der Zeitumstellung und die Schaltsekunden sind nicht so nett.
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
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
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?
1 | #include <stdio.h> |
2 | #include <time.h> |
3 | |
4 | int main() |
5 | {
|
6 | printf("sizeof(time_t): %u\n", (unsigned int)sizeof(time_t)); |
7 | }
|
1 | $ ./a.out |
2 | 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!
Epoch = 1.1.2000 Wenn der 32 Bit Zähler überläuft habe ich ganz andere Probleme ;-)
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/
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
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.
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.
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.
... 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/depreciated/10_Timeseries-curve-types_v1r1.pdf
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.
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.