Wetterstation

  • Hallo,


    neben der Heizungssteuerung ist die Wetterstation ja eines der beliebtesten Bastelprojekte :)
    An anderer Stelle hier im Forum wurde der HP03S und der HH10D angesprochen, die durch den i2c Bus ideale Sensoren für den Pi sind.
    Ich habe mich auch mit dem HP03S beschäftigt und möchte das Ergebnis hier vorstellen.


    Hardware:


    Beim HP03S gibt es zwei Besonderheiten zu beachten, damit man ihn am i2c Bus betreiben kann.
    1) über einen GPIO Pin muss dem Sensor mitgeteilt werden, ob der ADC aktiv ist oder das EEPROM mit den Kalibrierungsdaten.
    Der Pin muss auf LOW liegen, um die EEPROM Daten auszulesen und auf HIGH, um den ADC zu aktivieren. Das erledigt man am
    sinnvollsten über einen GPIO
    2) Der Sensor benötigt für den ADC ein Taktsignal von 32kHz. Der genaue Takt soll eher unkritisch sein (zw. 30 und 35 kHz) aber der
    Stromverbrauch wird geringer, je steiler die Flanken des Taktsignals sind. Ich habe hierfür eine Anregung von Orb aus einem anderen Thema
    übernommen (Off-Topic/selber löten/Betrag 22 - hab noch nicht herausgefunden, wie man das direkt verlinken kann :-)) und den Takt mit einem
    4001 4 fach NOR und einem Uhrenquarz erzeugt. Der 4001 kostet knappe 10ct, der Uhrenquarz ca 25ct.


    Software:
    EEPROM lässt sich mit i2cget und i2cdump von der Kommandozeile auslesen, Den ADC bedient man am besten per Programm, zumal man ja
    auch noch rumrechnen muss, um die gewünschten Werte zu erhalten.


    Hier der Code:
    Es ist da möglicherweise noch ein Fehler drin. Der Luftdruck ist zwar in einem plausiblen Bereich, kommt mir aber viel zu niedrig vor. (995 hPa, während
    die nahe Wetterstation 1022 hPa meldet)
    Temperatur hingegen scheint 100% korrekt rüberzukommen.



    Und hier ein kleines Testprogramm:




    So, das wars erst mal. Vielleicht hat ja jemand eine Ahnung, woran das mit dem zu geringen Luftdruck liegen könnte



    Gruß
    Odin

  • Quote from odin pid=7007 dateline=1362344739

    hab noch nicht herausgefunden, wie man das direkt verlinken kann :-))


    Moin,


    ich öffne immer ein zweites Fenster, gehe auf den Link, kopiere mir die URL und dann füge ich diese in den Text ein.


    Ich habe auch beide Fühler, wie gesagt, ich warte auf Teile.


    Leider sind meine Elektronik- und C- Kenntnisse nicht sehr gut, bin mich gerade am reinarbeiten.


    Bis jetzt habe ich 4x DS18S20 Temperatursensoren (+Prozessortemperatur) die ich über php und cronjob mit Zeit- und Datumserfassung in eine Datenbank gebe.
    Ich beschäftige mich gerade mit der Graphischen Ausgabe über gd-lib. Das Prinzip habe ich verstande, das nächste Ziel ist es, die Datenbank an zu binden.


    Hast du auch vor eine Wetterstation zu bauen?


    Mein Ziel ist es, eine Wetterstation, autark, im Garten zu betreiben.
    Energieversorgung über Sonne, Wind, Windrichtung, Regen, Temperaturen (Boden, 1,8m Windchill).
    Das alles soll nachher auf einer schönen Seite mit Messdaten, in Tabellen- und Graphischer Form, ausgegeben werden.


    Mit der Zeit die ich habe, denke ich das es im nächsten Winter funktionieren sollte.


    cu Pfaelzer

  • Hallo,


    pfaelzer


    ich habe mir den Raspberry angeschafft, um herauszufinden ob er die typischen Aufgaben eines Microcontrollers übernehmen kann und dabei dem Komfort eines Linux PCs bietet.
    Eine Wetterstation hatte ich dabei ursprünglich nicht im Sinn, aber bei den ganzen Ideen, die man hier so liest, könnte es ein interessantes Projekt sein. :)


    Schreiten wir also zu Tat :)


    Der HH10D ist ein gutes Beispiel dafür, daß ein Raspberry einen Microcontroller nicht (zmindest nicht vollständig) ersetzen kann. Die Frequenzmessung, die für den HH10D
    nötig ist scheitert am Multitasking und an einem fehlenden Ereigniszähler. Wenn es wenigstens einen i2c auslesbaren Counter gäbe, zumindest finden konnte ich keinen.


    Mit dem Pi kann man bestenfalls Zyklen zählen und die Zeit stoppen. Dadurch, daß die Prozesse dabei ständig unterbrochen werden, ist diese Methode extrem ungenau.
    Einen ersten Versuch hänge ich mal an, aber daran kann man schon erkennen, daß man den HH10D besser im Schrank liegen lässt und sich nach einem Baustein umsieht,
    der für den IO des RPi besser geeignet ist.



    In den nächsten Tagen werde ich noch versuchen, die Zählfunktion durch eine C-Routine zu ersetzen und nachsehen, ob man einen genaueren Timer
    auf dem RPi findet, aber viel Hoffnung mache ich mir dabei nicht.
    Vielleicht hat ja jemand eine bessere Lösung (ohne externen Microcontroller :-))


    Die 1820 hatte ich in einem anderen Projekt schon mal am laufen. Das geht ganz gut mit einem DS2482 am i2c. Es gibt hierfür zwar auch eine Softwarelösung aber da der 1-wire
    Bus auch zeitkritisch ist, halte ich die Hardwarevariante für zuverlässiger. Zumal der DS2482 auch nur Pfennigskram ist.


    Gruß
    odin

  • Hallo,


    der SHT21 hört sich interessant an. Leider bewegt sich der Preis irgendwo an der äusseren Grenze für ein Bastelprojekt.
    Aber so schnell will ich mit dem hh10d noch nicht aufgeben.
    Die Periodenmessung mit dem Pi in Pythion funktioniert ja, ist halt nur viel zu ungenau. Ein Ansatz wäre, möglichst viel Zeit
    in der Zählschleife zu verbringen. Eine externe C-Funktion, die die mittlere Periodendauer misst, sollte das optimieren. Aber externe C-Funtionen in Python
    sind zumindest für mich als Anfänger nicht gerade ein unerheblicher (Lern-) Aufwand.


    Ich hatte da noch eine andere Idee: Das Signal liegt mit 7-8 kHz mitten im besten Abtastbereich für Soundkarten. Da es sich um ein Rechteck Signal handelt, müsste man
    nicht mal Herrn Fourier bemühen, sondern es würde genügen zwei Schwellwerte zu betrachen.
    Im Grunde ein paar Sekunden /dev/dsp auslesen, zählen, wie oft ein gewisser Schwellwert überschritten wird und anhand der Samplingrate lässt sich die
    Frequenz ziemlich genau ermitteln.


    Und da kam der Punkt, an dem ich nach fast 20 Jahren das erste Mal wirklich über Linux fluchen musste. ALSA, OSS, Pulseaudio, etc etc etc.
    Solange man nur Musik abspielen wollte, war Audio bisher nie ein Problem, aber wenn man den Audiotreiber direkt ansprechen will endet man heute offenbar in einem
    babylonischen Treibergewirr.


    Nach gefühlten 100 Versuchen, Treiber zu laden, Wrapper zu installieren, Config Files anzupassen, habe ich so ziemlich jede Fehlermeldung von 'File not Found' bis
    'Connection Refused' gelesen ohne auch nur ein Byte von der Soundkarte zu lesen :(


    Hat es schon mal jemand geschafft, /dev/dsp oder /dev/audio auszulesen oder kennt jemand eine Alternative zu ossaudiodev... ihr wisst schon... :)



    Gruß
    Odin

  • ähh, der Pi hat keinen Audio-Eingang verfügbar. Du müßtest eine USB-Sondkarte benutzen.
    Und ja, Audio unter Linux war schon immer krampfig, inzwischen hat man sich wenigstens auf ein Treibermodell geeinigt. Ich muß meinem Chef mal sagen, daß ich ein halbes Jahr Urlaub will damit ich mir das mal alles in Ruhe ansehen kann.

  • sorry, hätte ich erwähnen sollen: Audio kommt über einen USB Soundstick rein.
    Bin auch schon ein Stückchen weiter. Der Eingang des Sticks belastet die Signalquelle so stark, daß das Rechteck sich zu einen Sägezahn verformt.
    Schwellwerte messen kann man also vergessen. Immerhin konnte ich ALSA überreden, mir die Daten zu liefern.
    Wenn man sich das mit einem FFT Tool z.B. aus Audacity ansieht,gibt es tatsächlich einen Peak bei der Frequenz des Sensors und der ist sogar erstaunlich genau.
    (ca 20 Hz Diff zum Frequenzzähler)
    Leider ist FFT nicht unbedingt mein täglich Brot. Am Wochenende suche ich mal, ob es was fertiges gibt. Wenn nicht muss eben doch ein anderer Baustein her.


    Gruß
    Odin

  • Hi,


    es ist zwar eher als 'proof of concept' zu verstehen, als daß man wirklich etwas damit anfangen könnte, aber hh10d per Soundkarte funktioniert :)
    Leider ist der Aufwand zu hoch um praktikabel zu sein.


    Benutzt habe ich einen billig Soundstick für knappe 5 EUR, der das Eingangssignal leider stark verzerrt. Auf eine extra Verstärkung habe ich verzichtet, lediglich das Signal
    über 10nF eingekoppelt um nicht die Gleichspannung des Mikrofoneinganges auf den Frequenzausgang des Sensors zu geben.
    mit dem ALSA Tool arecord ein paar Sekunden aufgezeichnet und mit SOX in eine für FFT geeignete Textdatei umgewandelt. ('sox sound.wav sound.dat' genügt schon)
    Danach kann man mit einem FFT Tool (z.B. http://anonsvn.loudet.org/fft/…rc-linux/fft-1.0.0.tar.gz) daraus eine Datei generieren, die den Frequenzgang in
    dB beschreibt.
    In dieser Datei muss man dann nur noch den höchsten Pegel suchen und hat die gewünschte Frequenz gefunden.
    Das Ergebnis ist ziemlich genau und vor Allem im Gegensatz zum Flankenzählen in Python extrem stabil.
    Aber ein direkt per i2c auslesbarer Sensor ist mir dann doch lieber :)


    Spätestens beim Messen der Windgeschwindigkeit ist das Problem der Frequenzmessung wieder da, auch wenn die zu messende Frequenz dort wesentlich geringer ist.


    Gruß
    Odin

  • Sorry, ich muss das in mehreren Stücken posten, wenn ich das Ganze als eine Antwort schreibe, schneidet das Forum meinen Text etwa in der Hälfte ab :(


    Hallo,


    evil: cool, ich bin begeistert. den 8583 als Zähler probiere ich die Tage noch aus. Außerdem steckt in Deinem Dokument möglicherweise die Antwort auf ein Problem, das mit heute abend
    erst aufgefallen ist. (s.u.)
    Ich finde es besonders bemerkenswert, wie Du Standardtools verwendest, statt gleich zum Compiler zu greifen :)



    Ich fasse hier mal schnell meine Ergebnisse der letzten Tage zusammen:




    Luftdruck
    ---------
    Der HP03S hat die ganze Zeit schon den Druck korrekt angezeigt. Ich habe vor lauter i2c, Takterzeugung und Umrechnerei verpeilt, daß sich die wenigsten von uns auf Meeresniveau
    befinden ;) Nach Anpassung des Wertes stimmt das Ergebnis exakt mit dem der eingangs erwähnten Wetterstation überein.


    hier die korrigierte Lib.




    Temperatur
    ----------


    1-wire ist hier ja schon täglich Brot, da gibt es nicht mehr viel zu zu sagen. Nach Anregung an anderer Stelle im Forum habe ich die Softwarevariante über GPIO noch einmal ausprobiert und bin begeistert. Bisher gabe es keinen einzigen Konvertierungsfehler offenbar hat sich seit den ersten Gehversuchen der w1-gpio einiges getan.
    Ich beobachte das noch etwas und wenn sich der aktuelle Eindruck bestätigt, werde ich auch bei kritischeren Messungen künftig auf die Hardwarelösung verzichten.


    Der Vollständigkeit halber hier auch die Lib für 1-wire Temperatur



    [hr]
    Teil 2...


    Feuchte
    -------
    Das Schwestermodul zum HP03S, der HH10D ist wie weiter oben nachzulesen nicht trivial zu bedienen. Flankenzählen ist zu ungenau, der Umweg über Soundkarte zu kompliziert und
    aufwändig.
    Es gibt wohl zwei i2c Sensoren, den HYT939 und den SHT21, beide (letzterer mit Breakout Board) kommen so um die 30 EUR.
    Ziemlich teuer zumal mal bei einem bekannten Versender zur Zeit für knapp 80 EUR Luftdruck, Feuchte, Windrichtung und Geschwindigkeit bekommt
    (wenn man es schafft, mit dem USB von dem Ding zu reden)
    Von evil kam jetzt noch eine Anregung, den pcf8583 als Zähler zu verwenden. Sowie ich die nächsten Tage die Zeit finde, probiere ich das noch aus, bevor ich den Sensor
    zu den Akten lagen



    Betrieb
    -------


    Der RPi hängt mit einem Logilink WL0084B an einem Access Point. Sehr unzuverlässig. Der USB Adapter verliert selbst bei einer kurzen Entfernung permanent die Verbindung. Vielleicht
    kennt ja jemanden einen etwas stabileren USB WLAN Stick.


    Ein Python Programm (bin kein Python Fanatiker, kenne mich nicht mal besonders gut damit aus - aber Python soll ja die Sprache des RPi sein) läuft in einer Endlosschleife und schreibt
    die ausgelesenen Werte nach /dev/shm um nicht zu viele Schreibzyklen auf der SD Karte zu erzeugen.


    Hier der Code





    Ab hier kann man mit shell, perl und Unix Tools arbeiten, wo ich mich etwas mehr zu Hause fühle :)
    Eines dieser Tools ist 'rrdtool', das dem ein oder anderen aus Cactii oder Centreon bekannt sein dürfte. In rrdtool steckt im Grunde alles drin, was man für eine solche Aufgabe
    benötigt.
    Ein 'ausgewachsenes' Datenbanksystem wie Postgresql halte ich zu diesem Zweck für mit Kanonen auf Spatzen geschossen. Ausserdem erzugen solche Systeme auch im Leerlauf
    ziemlich viel vermeidbaren I/O auf der SD Karte.
    Wenn man auf eine dauerhafte Speicherung der Messwerte nicht verzichten kann, würde ich an dieser Stelle auf sqlite oder einfach eine Textdatei zurückgreifen.


    Die RRD Datenstruktur wird folgendermassen angelegt:




    sieht komplizierter aus, als es ist. Es gibt diverse gute Tutorials, zu dem Thema rrdtool. Man gibt im Grunde an, wie oft man Daten erwartet (z.B. --step 300: alle 5 Minuten), was man
    speichern will, welchen voraussichtlichen Wertebereich die Daten haben und wie viele Werte man aufheben will, bevor die ersten Werte wieder überschrieben werden.


    Ein kleines perl Script wird in der crontab alle 5 Minuten gestartet. Dabei liest es die vom oben angesprochenen Programm erzeugte Datei und fügt die Werte mittels rrdtool in die rrd
    Datenbank ein und schreibt sie zusätzlich mit einem Zeitstempel in eine Textdatei, die man dann später auslesen und z.B. in eine Datenbank einfügen kann.




    Wenn die Werte geschrieben sind, möchte man sie natürlich visualisieren. Auch diese Aufgabe übernimmt wieder rrdtool. Das folgende shell Script generiert aus den gelesenen
    Daten jeweils 3 Grafiken für Temperatur und Luftdruck (5 Stunden, 24 Stunden und 5 Tage).




    Die Grafiken lassen sich dann in eine statische Webseite einbinden. Wenn man auch diese Shell Script per Crontab aufruft, ist die Webseite auch ohne viel Programmierung immer aktuell.


    Anbei noch 2 Beispielgrafiken. Beim Luftdruck sieht man, daß das Teil die ganze letzte Woche korrekt gemessen hat. Erst heute nachmittag stimmen weder die Temperaturen noch der
    Luftdruck. Heute nacht sind die Werte wieder korrekt.
    Mir ist in dem Dokument von evil aufgefallen, daß dort bei der Unterscheidung der Temperatur zweimal die gleiche Formel steht, also kein anderer ROM Parameter ab einer bestimmten
    Temperatur verwendet wird.
    Ist das Absicht?
    Ich habe nämlich das Gefühl, daß der Fehler durch die vergleichsweise hohen Temperaturen heute im Zusammenhang mit dem 'if' steht und das Ergebnis richtig wäre, wenn man diese
    Unterscheidung nicht machen würde.


    Gruß
    Odin

  • Hallo Odin,


    habe auch solch eine Wetterstation gebaut. Für den Luftdruck habe ich sowohl den gleichen Sensor als auch die gleiche Python Lib verwendet (habe nur die Messungen zusammengefasst, so dass nicht jedesmal gemessen werden muss wenn Temperatur und Druck nacheinander abgefragt werden). Bei meinem System konnte ich bisher noch nicht solche Fehler bei der Messung feststellen. Ich habe dir mal für die letzte Woche den Druckvergleich angehangen.


    [Blocked Image: http://www.goetzke-online.de/images/pressure_w.png]
    Also ich glaube die Messungen sind ok (grün ist der Durchschnitt für die Woche), zumal die Werte ziemlich gut mit denen der Wetterstation korrelieren.


    Nebenbei bemerkt, sind die RRDTools für die Datenerfassung aus Auswertung optimal. Ich habe jetzt schon einiges an Daten drin (messe seit Anfang Januar).


    Grüße


    Voidpointer