Regenmesser zu Ethernet oder USB - mein erstes Arduino-Projekt?

Die ist in der Tat sehr schön, danke!

Grüße Marc

--

-------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Mit Ratten meinst Du also Bugs.

Grüße Marc

Hübsch. Der nächste Meßpunkt ist aber locker 10 km weit weg (in Schwetzingen).

Grüße Marc

Dunkel sind Deiner Worte Sinn. Die PTB bietet historische Niederschlagsdaten an?

Grüße Marc

Stichwort "Eichen". Der Normalbürger eicht nicht, der kalibriert. Wenn es um Eichen geht ist die PTB der Ansprechpartner...

Gerald

Das funktioniert so nicht. Niederschlagsmengenmessung ist immer an den Ort der Erfassung gebunden. Da hilft nur eine definierte Menge Wasser auf die man kalibrieren kann.

Gerald

Hi Marc,

Ratten, Käfer, Schaben, Ungeziefer aller Art und auch Schimmel, Moder und was man sonst alles nicht gebrauchen kann.

Marte

Am 19.07.2019 um 10:39 schrieb Marte Schwarz:

Ich hatte an der Stelle enc28j60 gemeint. Das ist ein LAN Baustein. Aber ESP8266 bzw. WLan ist da eh praktischer.

snipped-for-privacy@web.de (Gerald Oppen) am 20.07.19:

Das sollte der OP definieren. Ich weiß nicht, in welchem Raster er die Daten erfassen möchte. Minütlich? Stündlich? Wöchentlich? Immer, wenn ein Liter zusammengekommen ist? Bei jedem Klick der Regenwippe?

Für mich wäre ein Niederschlagslogger, der mal im Minuten-, mal im Stundentakt loggt, dann aber auch mal eine Woche Pause macht, irgendwie sinnbefreit. Dann kann ich auch aus dem Fenster schauen und schätzen oder einen Sammeleimer aufstellen.

Naja, diese Billig-DSxxxx Uhr läuft im Monat maximal einige zehn Sekunden falsch. Dafür kostet sie halt fast nix. Es gibt auch welche, die zwei oder drei ppm Abweichung bieten, sind aber latürnich teurer.

Wenn eine solche geringe Abweichung in dem Regenlogger dazu führt, daß die Echtzeit nichts wert ist, wie paßt das dann mit der Aussagekraft von Meßwerten zusammen, die in mehr oder weniger zufälligen, möglicherweise tagelagen Abständen erfaßt und vom Host zeitgestempelt werden?

In einem gebe ich dir freilich recht: Die RTC ist überflüssig, wenn man keine absoluten Zeitstempel benötigt und der µC-Takt "genau genug" ist. Der OP scheint sich einen Uno mit Quarz ausgesucht zu haben, da kann man auf maximal 100ppm Abweichung hoffen, was für die Anwendung genau genug ist, wenn der Host oft genug nachguggt. Nach einer Woche ohne Korrekturwert kann man halt eine Minute Abweichung ansammeln. Bei einem Arduino mit Keramikresonator kann es hingegen auch mal eine halbe Stunde sein und über einen Attiny oder atmega mit internem RC- Oszillator denken wir lieber nicht nach, da rechnet man in Prozenten, nicht in ppm ;-)

Gewiß. Und genau deshalb wäre es schön, wenn der µC sich die Zeitstempel selber geben würde und nicht von einer unregelmäßigen Anbindung an einen Host abhängig wäre. Welchen Aussagewert bei einem Logger hat die Information "50 klicks seit der letzten Abfrage", wenn die Abfrage mal nach einer Stunde, mal nach drei Tagen erfolgt? Siehe "aus dem Fenster guggen" -> war wohl viel Regen, war wohl wenig Regen. Aber das mit NTP-genauem Zeitstempel ;-)

Die SD-Karte war als *eine* Möglichkeit für eine billige Speichererweiterung angeführt, wenn die paar hundert Byte internes EEprom nicht reichen. Und die reichen nicht weit, btdt.

Rainer

Echt? Also ich würde da eher einen Botaniker fragen wenn ich zu Eichen Fragen hätte.

Gerrit

Hallo,

Am 20.07.19 um 07:52 schrieb Marte Schwarz:

Alle meteorologischen Daten sind wertvoll, quakte der Wetterfrosch. Ich muss mein Diplom schließlich in Ehren halten.

Warum sollte man diese Daten schreiben, wenn sich nix getan hat? Je nach Gegend hast Du in Deutschland locker mal 150 Tage ohne Niederschlag. Warum nicht einfach nur bei Änderungen schreiben? Ich würde mit maximal 30 Tsd/Jahr Stunden Niederschlag rechnen. Keine Änderung? Kein Schreiben!

Man könnte sich so etwas wie einen Ringbuffer überlegen, der aber nur beschrieben wird, wenn sich die Daten ändern. Denn schreibt man dann einfach nach Ablauf eines Interval raus. Bei rund 1 Tsd Einträgen würdest Du bei stündlichen Einträgen weit über einen Monat Dauerregen brauchen um den RingBuffer einmal voll zu schreiben. Ganz grob würde ich da mit 3 Schreibvorgängen im Jahr rechnen. Gehe runter auf eine Viertelstunde und Du hast irgendwas um die 10 oder 12 Schreibvorgänge jedes Jahr. Nehme etwas weniger vom EEPROM, so die Hälfte(?) und dann hättest zu 25 oder so ... Und das sollte ziemlich weit reichen.

Da muss man sich nur Gedanken mit den Ein-/Aus-Vorgang machen und wie man das Ende des RingBuffers bei Neustart erkennt? Hat da jemand eine gute Idee? Das erste Bit alternieren und nur die restlichen Bit für den Zähler nehmen?

Neustart: Suchen nach Datensatzende und dort weiter machen.

int iPos = ThisSearch() Suche nach Datensatzende: Erstes Bit im folgenden Datensatz ist ungleich.

ThisWrite(iCounter,iPos) Schreiben: Erstes Bit togglen und Zählerstand dran hängen.

int iCounter = ThisRead(iPos) Lesen: Differenz zwischen aktuellem und letzten Zählerstand ist die Zahl der Klicks im Intervall.

int iCounter = GetCounter() Datenholen: Zählerstand auslesen ... Der liegt im RAM und wurde durch eine ISR hochgezählt.

Dazu definiert man noch FIRSTPOS und LASTPOS des Ringbuffer und damit sollte man durchkommen?

main() iPos = ThisSearch(); ThisCount = ThisRead(iPos);

Zeitschleife ggf in oder über Timerinterrupt oder RTC?

LastCount = ThisCount; ThisCount = GetCounter(); if ( ThisCount > LastCount ); { iPos++; if (iPos > LASTPOS) { iPos = FIRSTPOS; } WriteThis(iCounter,iPos); }

Habe ich da einen Denkfehler gemacht? Kommt schon! Nennen wir das ganze doch einen LogRingBuffer? *grins*

MfG

Uwe Borchert

Wahrscheinlich meinst Du etwas anderes, auf das ich gerade komme, aber ich erwarte in der Regel Niederschlag nie an mehr als 8765 h/a.

-- /¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067 \ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069  X in | D-50829 Köln-Ossendorf

Kommt auf die Lösung an... Wenn man die Niederschlagsmenge pro Zeiteinheit haben möchte muss man auch eine Zeitinformation haben. Die bekommt man aber auch hinreichend genau z.B. mit einer minütlichen Abfrage wenn man auf +/-1 Sekunde genau die Messwertübertragung garantieren kann.

Gerald

snipped-for-privacy@gmx.de (Marte Schwarz) am 20.07.19 um 07:52:

Für den Regenlogger sicher ausreichend.

Wobei... der aktuell hier stattgefundene Schüttregen dauerte gerade einmal 15 Minuten. Wenn man solche Peaks erfassen will, muß man wohl doch öfters zeitstempeln ;-)

Aber wieviel Speicher brauchen wir wirklich?

Wenn wir von der maximal erwarteten Frequenz von 3 Hz ausgehen, reicht ein Byte für 85 Sekunden Gewaltregen, was den Begriff "Überlauf" erklärt. Etwas knapp, also brauchen wir ein unsigned int dafür, mithin zwei Byte. Da passen dann sechs Stunden Zählimpulse mit Maximalfrequenz rein, bei solchem Wetter dürfte der Host-PC schon deutlich unter Wasser stehen, wenn der im Erdgeschoß untergebracht ist. In diesen Zähler würde auch fast das Doppelte des Hamburger Jahresniederschlags passen. Also Reserve satt ;-)

In einem kB EEprom kann man folglich 512 Meßwerte unterbringen, wenn man auf einen Zeitstempel verzichtet. Daraus und dem gewünschten Zeitraster ergibt sich, in welchen Abständen der Host-PC die Daten abholen muß, damit keine Datensätze verloren gehen. Bei einer Abfrage innerhalb von 24 Stunden sind dann knapp drei Minuten Abstand zwischen zwei Logger-Einträgen. Mißt man nur alle 10 Minuten, darf die Abfrage dann auch mal drei Tage pausieren.

Rainer

EEPROMs werden üblicherweise zellenweise geschrieben/gelöscht während Flash blockweise behandelt wird. Müsste also pro Zelle gelten.

Gerrit

snipped-for-privacy@laosinh.s.bawue.de (Gerrit Heitsch) am 20.07.19:

Nein. Jedenfalls nicht bei diesen seriellen EEproms. Wie es die Atmegas intern machen, weiß ich nicht, aber die 24LCxxx schreiben /immer/ den ganzen 64-Byte-Block, egal, ob im Blockmode oder im Byte Mode geschrieben werden soll. Nennt sich im Datenblatt "refresh".

Gut, das sind immerhin kleinere Abschnitte als bei gängigen Flash.

Rainer

Hallo,

Am 20.07.19 um 16:37 schrieb Axel Berger:

Das ist durchaus plausibel für Durchschnittswerte. Mein 30 Tsd h/a waren ein Stellenfehler. 3000 h/a wären eine übertrieben Schätzung auf der Basis der Regentage. Aber echte Daten?

Ich kenne nur die offiziellen Daten der Regentage vom DWD, sowie einige Meldungen aus weniger offiziellen Quellen die von mindestens

MfG

Uwe Borchert

Hallo,

Am 20.07.19 um 16:26 schrieb Uwe Borchert:

Hier habe ich einen Fehler gemacht. Ich meinte 3000 h/a. Danke an Axel B. für den Hinweis. Aber real scheint es sogar noch weniger zu sein. So 500 bis 1000 h/a sollte man erwarten, das hat eine kurze Suche im Internet gebracht. Das entspräche dann so rund 3 h Regen pro Regentag. Leider habe ich dazu keine offiziellen Datenquellen (DWD) gefunden.

Hier fehlt was: ... ist ungleich oder aber alle Ersten Bit haben das gleiche Vorzeichen, dann war der letzte Wert (bei LASTPOS) das Datensatzende.

Damit sollte es jetzt schon etwas fehlerfreier sein?

MfG

Uwe Borchert

... kann diese aber im RAM zwischenlagern. Regen und Stromausfall zusammen ist ein Risiko das ich in Kauf nehme.

Wieviel Liter pro m² fielen dann in diesen 15 Minuten?

Man könnte auch die Impulse pro Minute zählen und damit die Anzahl der Datensätze (Zeitstempel plus 8 Bit Zähler) auf 60 prO Stunde reduzieren. Genauer brauch ich's nicht.

Serverraum im Keller. Flutsicherer dürfte das Gartenhaus sein, wenn es nicht weggeblasen wird. Dann ist allerdings auch der Regenmesser mit weg, der ist am Gartenhaus montiert.

Grüße Marc