Regenmesser zu Ethernet oder USB - mein erstes Arduino-Proje

[Marc Haber]

Heinz Schmitz <kma@kma.org> wrote:

Marc Haber wrote:
ich habe einen Regenmesser aus China mit einer Wippe mit einem
Impulsausgang.

Zur Eichung lässt sich dann diese Webseite hervorragend verwenden:
https://www.proplanta.de/Wetter-Statistik/Suche/
nach Bundesland, Ort, und Datum.

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

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

 

[Marc Haber]

Andreas Neumann <an5275@sedo.com> wrote:

Heinz Schmitz wrote:

Zur Eichung lässt sich dann diese Webseite hervorragend verwenden:
[snip]

Kaum, dafĂźr wohl eher diese Seite:
https://www.ptb.de/cms/

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

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

 

[Rainer Knaepper]

bernd.laengerich@web.de (Bernd Laengerich) am 19.07.19 um 21:45:

Am 19.07.2019 um 20:47 schrieb Marc Haber:

Du kannst Dich ja gerne weiter darüber lustig machen. _Ich_ weiß
was ich kann und was nicht.

Sorry wenn das negativ 'rüber kam, ich wollte eigentlich nur
ausdrücken daß die EEPROM-Idee ja schon durch war.

Wobei ich die Angst vor dem EEprom nicht verstehe. In Assembler muß
man wegen des Timings und der Zugriffssequenz schon genau aufpassen,
aber für Arduino gips doch Bibliotheken bzw. fertige Funktionen, so
daß das nicht viel schwieriger ist, als einen Portpin abzufragen.

Das interne EEprom ist für die Verwendung als Logger freilich schon
mehr als arg klein. Ich habe mir beim letzten Besuch beim freundlichen
Chinamann deshalb mal so SD-Karten-Adapter mitbestellt, allerdings
bislang noch nix damit gemacht.

Rainer

--
Man kann andauernd wundern.
(Stephan Kendzia in de.comp.hardware.drucker)

 

[Gerald Oppen]

Am 20.07.19 um 12:40 schrieb Marc Haber:

Andreas Neumann <an5275@sedo.com> wrote:
Heinz Schmitz wrote:

Zur Eichung lässt sich dann diese Webseite hervorragend verwenden:
[snip]

Kaum, dafĂźr wohl eher diese Seite:
https://www.ptb.de/cms/

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

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

Gerald

 

[Gerald Oppen]

Am 19.07.19 um 10:47 schrieb Heinz Schmitz:

Marc Haber wrote:

Hallo,

ich habe einen Regenmesser aus China mit einer Wippe mit einem
Impulsausgang.

Zur Eichung lässt sich dann diese Webseite hervorragend verwenden:
https://www.proplanta.de/Wetter-Statistik/Suche/
nach Bundesland, Ort, und Datum.

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

 

[Marte Schwarz]

Hi Marc,

> Mit Ratten meinst Du also Bugs.

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

Marte

 

[Stefan]

Am 19.07.2019 um 10:39 schrieb Marte Schwarz:

Hi Marc,

Mein Vorschlag wäre ENC8266.

Den find ich bei Amazon nicht.

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

Dann tipp mal ESP8266 in ebay und such Dir den aus, der mechanisch am
Besten zu Deinen Vorstellungen passt. Ich schwenke gerade auf ESP8285
um, ist im Prinzip der direkte Nachfolger. Der ESP-09 ist einfach zu
schwer zu bekommen und dann zu teuer. Die ESP-01F oder auch die ESP-M1
sind einfach schĂśner und noch einen TUC sparsamer...
Wenns nicht ganz so klein sein muss und Di kaum externe Pins brauchst,
dann schau nach ESP-01 oder ESP-12.

Mit Arduino gehen die auch, wie die ESP8266.

Eine gute Zusammenfassung fĂźr den Umgang damit findest Du bei
http://www.stefanfrings.de/esp8266/index.html

Viel Spaß

Marte

 

[Gerrit Heitsch]

On 7/20/19 1:03 PM, Gerald Oppen wrote:

Am 20.07.19 um 12:40 schrieb Marc Haber:
Andreas Neumann  <an5275@sedo.com> wrote:
Heinz Schmitz wrote:

Zur Eichung lässt sich dann diese Webseite hervorragend verwenden:
[snip]

Kaum, dafĂźr wohl eher diese Seite:
https://www.ptb.de/cms/

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

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

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

Gerrit

 

[Uwe Borchert]

Hallo,

Am 20.07.19 um 07:52 schrieb Marte Schwarz:

Hi Gerrit,

100k Zyklen sind im Minutentakt erschreckend schnell verbraucht.

Ja, 1440 min pro Tag, nach 70 Tagen ist rum. Bei 1 Mio. wären es
700 Tage.

Ich weiss ja nicht, wie wertvoll die Niederschlagsdaten sind.

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

... Ich wĂźrde eben einmal pro Stunde oder auch einmal pro Tag die
Daten vom RAM ins EEPROM schieben und den Rest im RAM 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!

... Und wenn dann tatsächlich mal was schief gehen sollte, dann ist
ein Datensatz verloren. Meine Welt geht davon nicht unter. ...

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

 

[Axel Berger]

Uwe Borchert wrote:
> Ich wĂźrde mit maximal 30 Tsd/Jahr Stunden Niederschlag rechnen.

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 http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

 

[Gerald Oppen]

Am 19.07.19 um 12:22 schrieb Peter Heitzer:

Gregor Szaktilla <spam0.sz@ktilla.de> wrote:
On 19.07.2019 10:35, Marc Haber wrote:
Gregor Szaktilla <spam0.sz@ktilla.de> wrote:
On 18.07.2019 22:20, Marc Haber wrote:
Hat ein laufender Arduino eine halbwegs genaue Echtzeituhr?
Nein. Man kann zwar mittels millis() erfragen, wie lange in ms der
Arduino schon eingeschaltet ist, aber es dĂźrfte kaum zwei Arduinos
geben, deren millis()-Ticker synchron laufen. FĂźr genaue Messungen Ăźber
minutenlange Dauer sind die nicht geeignet.
Es gäbe eine regelmäßige Abfrage von einem System mit synchronisierter
Uhr, diese Abfrage kĂśnnte man zur synchronisierung nutzen (Client
liefert seinen Zeitstempel mit, der Arduino interpoliert).

Wenn es Dir nicht auf absolute Genauigkeit im ms-Bereich ankommt, ist
das absolut ausreichend. Wenn Du auch mit dem Arduino entwickelst, der
auch im Endprodukt eingesetzt wird, kannst Du bei Bedarf eine Korrektur
in Software vornehmen.

Ich denke, ein Zeitstempel ist auf dem Arduino Ăźberhaupt nicht nĂśtig.
IMO reicht es, bei jeder Abfrage eine Sequenznummer zu Ăźbertragen und
diese auf dem Arduino danach zu inkrementieren.

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

 

[Hans-Peter Diettrich]

Am 19.07.2019 um 21:20 schrieb Gerrit Heitsch:

On 7/19/19 8:38 PM, Rainer Knaepper wrote:
Bernd.Laengerich@web.de (Bernd Laengerich) am 19.07.19 um 14:45:

Der MEGA328 garantiert 100.000 Zyklen, die externen (unter einem
Euro) liegen bei 1Mio. Da kann man einfach recht schmerzfrei jede
Minute eine Änderung reinpusten.

100k Zyklen sind im Minutentakt erschreckend schnell verbraucht.

Worauf beziehen sich die Zyklen, auf eine Zelle oder das ganze EEPROM?

Man kann das EEPROM ja erst einmal vollschreiben, und wenn das alles
auch ausgegeben wurde, kann alles gelĂśscht und neu beschrieben werden.
Mit 100k LÜschzyklen käme man dann schon ganz schÜn weit.

DoDi

 

[Gerrit Heitsch]

On 7/20/19 9:38 AM, Hans-Peter Diettrich wrote:

Am 19.07.2019 um 21:20 schrieb Gerrit Heitsch:
On 7/19/19 8:38 PM, Rainer Knaepper wrote:
Bernd.Laengerich@web.de (Bernd Laengerich)  am 19.07.19 um 14:45:

Der MEGA328 garantiert 100.000 Zyklen, die externen (unter einem
Euro) liegen bei 1Mio. Da kann man einfach recht schmerzfrei jede
Minute eine Änderung reinpusten.

100k Zyklen sind im Minutentakt erschreckend schnell verbraucht.

Worauf beziehen sich die Zyklen, auf eine Zelle oder das ganze EEPROM?

EEPROMs werden ßblicherweise zellenweise geschrieben/gelÜscht während
Flash blockweise behandelt wird. MĂźsste also pro Zelle gelten.

Gerrit

 

[Rainer Knaepper]

Gerald.Oppen@web.de (Gerald Oppen) am 20.07.19:

Am 19.07.19 um 17:26 schrieb Rainer Knaepper:

Was aber eine ständig verfügbare Verbindung erfordert. So ein

Definiere "Ständig"...

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?

Den relativen Zeitstempel kann man so definieren dass er erst nach
Tagen überläuft. Wenn man aktuelle Messwerte haben möchte muss man
eh alle paar Minuten abfragen. Wenn man mal größere Abfragelücken
hat bekommt man trotzdem die komplette Niederschlagsmenge seit dem
letzten Abfragen, es wird nur die zeitliche Zuordnung ohne
zusätzlichen Maßnahmen schlechter.

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.

Echtzeit-Modul für den Arduino kostet nicht die Welt.
Muss aber überprüft werden ob es noch korrekt läuft, sonst ist die
Echtzeit nichts Wert. Bringt nicht wirklich einen Mehrwert.

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 ;-)

Die Frage, die sich mir freilich stellt, ist: Wenn ich eh ein
Kabel legen muß, wozu benötige ich dann überhaupt einen
Microcontroller, um einen einsamen Schaltkontakt abzufragen? Wenn
das übergeordnete System im Dauerbetrieb laufen muß, um sinnvolle
Zeitstempel zu erzeugen, kann man da auch irgendein USB-4-20mA
Adapterchen dranstricken und den Host-PC selber zählen lassen. 3
Hz kriegt man hin.
Der uC kann das viel besser als der Host. Der Host ist auch mal zu
Wartungszwecken etc. offline, den uC kann ich relativ einfach
Störungsfrei im Dauerbetrieb laufen lassen.

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 ;-)

Wenn schon ľC, dann sollte der auch was tun für sein Geld, also
mit korrekten Zeitstempeln autonom loggen und seine Datensammlung
auf Anfrage abliefern. Dann muß auch kein stromfressender PC im
Dauerbetrieb laufen. Der Chinamann liefert auch billige SD-
Kartenadapter, so daß man ziemlich lange Zeitreihen zwischenlagern
könnte.
Macht in der Anwendung wenig Sinn. Anfallende Datenmengen sind
gering.

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

--
Das Arbeiten mit Outlook Espress ist ein Schritt in die Steinzeit...
oder zumindest sehr gewöhnungsbedürftig.
(Peter Eggebrecht in de.comm.software.crosspoint)

 

[Rainer Knaepper]

marte.schwarz@gmx.de (Marte Schwarz) am 20.07.19 um 07:52:

Hi Gerrit,

100k Zyklen sind im Minutentakt erschreckend schnell verbraucht.

Ja, 1440 min pro Tag, nach 70 Tagen ist rum. Bei 1 Mio. wären es
700 Tage.

Ich weiss ja nicht, wie wertvoll die Niederschlagsdaten sind. Ich
würde eben einmal pro Stunde oder auch einmal pro Tag

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

--
Darüber hinaus ist er Österreicher (spricht also Deutsch)
(Der Rotstift in: z-netz.alt.esoterik)

 

[Uwe Borchert]

Hallo,

Am 20.07.19 um 16:37 schrieb Axel Berger:

Uwe Borchert wrote:
Ich wßrde mit maximal 30 Tsd/Jahr Stunden Niederschlag rechnen.

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

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
500 h/a schreiben und das war es dann. Pro Regentag also rund 3 h
Regen? So gesehen sollten 1000 h/a gut passen.

MfG

Uwe Borchert

 

[Rainer Knaepper]

gerrit@laosinh.s.bawue.de (Gerrit Heitsch) am 20.07.19:

On 7/20/19 9:38 AM, Hans-Peter Diettrich wrote:
Am 19.07.2019 um 21:20 schrieb Gerrit Heitsch:
On 7/19/19 8:38 PM, Rainer Knaepper wrote:
Bernd.Laengerich@web.de (Bernd Laengerich) am 19.07.19 um
14:45:

Der MEGA328 garantiert 100.000 Zyklen, die externen (unter
einem Euro) liegen bei 1Mio. Da kann man einfach recht
schmerzfrei jede Minute eine Änderung reinpusten.

100k Zyklen sind im Minutentakt erschreckend schnell verbraucht.

Worauf beziehen sich die Zyklen, auf eine Zelle oder das ganze
EEPROM?

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

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

--
Wer heute als Jugendlicher seine Zeit mit einer Modelleisenbahn
verbringt, ist eher peinlich, ausserdem hat der Standardjugendliche
gar keine Zeit mehr fuer so was. (MaWin in de.sci.electronics)

 

[Uwe Borchert]

Hallo,

Am 20.07.19 um 16:26 schrieb Uwe Borchert:

Am 20.07.19 um 07:52 schrieb Marte Schwarz:

100k Zyklen sind im Minutentakt erschreckend schnell verbraucht.

Ja, 1440 min pro Tag, nach 70 Tagen ist rum. Bei 1 Mio. wären es
700 Tage.

Ich weiss ja nicht, wie wertvoll die Niederschlagsdaten sind.

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

... Ich wĂźrde eben einmal pro Stunde oder auch einmal pro Tag die
Daten vom RAM ins EEPROM schieben und den Rest im RAM 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!

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.

... Und wenn dann tatsächlich mal was schief gehen sollte, dann ist
ein Datensatz verloren. Meine Welt geht davon nicht unter. ...

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.

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

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*

Damit sollte es jetzt schon etwas fehlerfreier sein?

MfG

Uwe Borchert

 

[Marc Haber]

Rainer Knaepper <rainerk@smial.prima.de> wrote:

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

.... 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?

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.

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.

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.

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
--
-------------------------------------- !! 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

 

[Falk DÂľebbert]

Am 21.07.19 um 11:16 schrieb Marc Haber:

Rainer Knaepper<rainerk@smial.prima.de> wrote:
Wobei... der aktuell hier stattgefundene SchĂźttregen dauerte gerade
einmal 15 Minuten. Wenn man solche Peaks erfassen will, muß man wohl
doch Ăśfters zeitstempeln;-)
... kann diese aber im RAM zwischenlagern. Regen und Stromausfall
zusammen ist ein Risiko das ich in Kauf nehme.

Also mein Regenzähler sendet "Beim Nächsten Ton waren es 30 Impulse" an
die Station. Bzw. er sendet seine Seriennummer. Quasi UDP.

Falk D.