Posts by odin

    schau Dir mal sixxs.net an. Es gibt noch einige andere. Ich habe da seit fast 3 Jahren ein eigenes ipv6 Subnetz und habe bisher keinen Grund zur Klage.
    Ist zwar auch letztendlich Knaup aber man bekommt einen Eindruck, wie es funktionieren könnte.
    Innerhalb meines lokalen Netzes haben alle Geräte v6 Adressen und am äußeren Router lässt sich leicht steuern, wer rein und wer raus darf.
    Dadurch, daß alle Geräte eine eigene Adresse haben, muss ich der Firewall eigentlich nur noch sagen, zu welchem Gerät ich welchen Port (meist 80) durchlassen will.


    Dumm ist halt, daß ipv6 von kaum einen Provider unterstützt wird, so daß du auf diese Weise z.B. mit Deinem Smartphone (das selbst zwar ip6 kann) aussen vor bist, weil Dein
    Provider lieber NAT über ein privates Netz betreibt.


    dyndns und Port Forwarding wird und noch eine geraume Zeit erhalten bleiben.


    Sicherheitstechnisch ist das allerdings nur deshalb etwas problematischer, weil dabei die Firewall Regln ein klein wenig mehr Aufmerksamkeit erfordern.
    Welches Problem siehst Du konkret bei der Freigabe eines RPi ober über v6 oder v4 ?




    Gruß
    Odin

    Hallo framp,
    der Grund, daß niemand bisher auf Dein Posting geantwortet hat, dürfte sein, daß die wenigsten von uns überhaupt die Möglichkeit einer vernünftigen Freigabe haben.
    Es fängt schon damit an, daß kaum einer feste IP Adressen hat, weshalb man auf Krücken wie Dynamischen DNS angewiesen ist. Selbst wenn Du eine feste Adresse hast, wirst Du
    bei mehr als einer richtig zur Kasse gebeten (ipv4), während ipv6 zurückgehalten wird, solange man aus dem Mangel an v4 Adressen noch Geld schlagen kann. Folge ist, daß Du mit
    Port Forwarding Murks arbeiten musst.
    Den RPi nach aussen freizugeben ist heute kein technisches Problem, sondern ein marktwirtschaftliches :(


    Solange es nicht um riesige Datenmengen geht, würde ich einen der kostenlosen ipv4/ipv6 Tunnel Provider bemühen und über ipv6 in mein lokales Netz reinkommen.
    Man kann IP Adressen und echtes DNS benutzen und muss keine Port Forwarding Verrenkungen unternehmen.
    Einfache Firewall davor und die Sache ist gegessen. IP-(nicht IT ;))-Sicherheit ist simpler, als man denkt.


    Auf kurz oder lang kommen wir um ipv6 nicht herum. Die Art und Weise, wie die ipv4 Leiche derzeit gefleddert wird ist mehr als unschön.


    Vielleicht bessert sich die Situation ja in naher Zukunft. Aber zur Zeit wäre ich froh, wenn ich beim Zugang von Außen technische Probleme lösen müsste :(



    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

    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

    Hallo MultiVitamin,


    es gibt meines Wissens zwei Möglichkeiten. Wenns nicht unbedingt owfs sein muss, gibt es ein Kernel Modul, das 1-wire direkt über GPIO spricht.
    Von Adafruit gibts ein Image, in dem das schon eingebaut ist.
    http://www.element14.com/commu…fruits-occidentalis-image
    Habe ich schon mal ausprobiert, funktioniert. Das Modul gibts auch zum Nachinstallieren für das 'normale' Raspbian
    Macht aber das Timing per Software, was ich bei einem Multitasking System etwas kritisch finde.
    Ich habe mich seinierzeit daher für die Hardwarevariante mit owfs entschieden. Du benötigst einen DS2482 1-wire Busmaster. Kostet wenn ich mich recht erinnere so um 1 EUR
    und wird an den i2c des RPi angeschlossen. OWFS kann dann direkt mit dem 1-wire eingerichtet werden. Funktioniert sehr zuverlässig, ist halt ein zusätzliches Stück (SMD-) Hardware.
    Ich wollte mich demnachst sowieso an anderer Stelle nochmal damit auseinandersetzen, ich werd dann mal ein paar Details posten.



    Gruß
    Odin

    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

    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

    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,


    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

    Hallo,


    der spezielle Baustein wäre wahrscheinlich nicht nötig gewesen. Das mit dem Quarz am Inverter funktioniert einwandfrei. Nachdem ich noch die zweite Stufe angeschlossen habe,
    sind die Flanken so steil wie mit dem Lineal gezogen.
    Der Vorteil der CMOS Bausteine ist ihr Preis. Ich vermute, der Taktgenerator ist nicht ganz billig?


    Für den Luftdrucksensor fange ich am besten in der Hardwareecke ein neues Thema an.


    Gruß
    Odin

    Hallo,


    ich hatte auch ein paar Anlaufschwierigkeiten mit dem HP03S und bin bei der Suche nach einer Lösung unter anderem auch auf das Thema hier im Forum gestossen.
    Vielleicht helfen meine Erkenntnisse ja dem ein oder Anderen weiter :)
    Takterzeugung:
    Im Grunde kann man jedes invertierende CMOS Gatter verwenden, wenn man den in der Beispielschaltung angegebenen Baustein nicht zu Hause hat. Bei ORs legt man den überflüssigen
    Anschluss auf GND, bei ANDs auf VCC. Unter Umständen muss man die Kondensatoren und R1 etwas anpassen um eine stabile Schwingung zu erhalten. Bei meinem 4001 4xNOR waren
    die 56p jedenfalls viel zu klein für die Frequenz.
    Zwischen 2n und 10n schwingt das Ganze sauber auf Quarzfrequenz.
    Also wenns nicht oder nur unkontrolliert schwingt einfach mal andere Werte für C1 und C2 sowie R1 (eher Richtung 10M) ausprobieren.
    VCC:
    Habe an anderer Stelle gelesen, dass der Sensor auch bei 5V noch antwortet, dann aber nur Müll vom ADC liefert (hab mich selber nicht getraut, das auszuprobieren :-)).
    Im Zweifelsfall prüfen ober man nicht 5V statt 3.3V an VCC liegen hat.
    I2C Adressen:
    Im Datenblatt steht 0xA0 und 0xEE. Beim RPi sind das 0x50 und 0x77.
    Die Register liefern nicht nur falsche Werte, wenn XCLR nicht richtig gesetzt ist, 0x77 ist nicht mal vorhanden, wenn XCLR auf LOW liegt. Das Register wird erst sichtbar,
    wenn man den PIN auf HIGH schaltet.
    Auslesen:
    EEPROM ist mit den i2c-tools i2c-get oder i2c-dump problemlos zu bedienen, beim ADC ist mir das nicht gelungen, da hier ja auch Kommandos gesendet werden müssen.
    Ausserdem muss man den XCLR bedienen, was man am besten über einen GPIO und nicht von Hand macht.
    Ich habe mir dafür eine kleine python Klasse bauen müssen, die nach einigem Hin und Her jetzt plausible Werte liefert.
    Falls Interesse besteht, kann ich die paar Zeilen Code gerne hochladen.


    Ganz zufrieden bin ich allerdings noch nicht:
    Die ausgelesene Temperatur ist erfreulicherweise viel genauer, als das Datenblatt vermuten lässt, den Luftdruck jedoch kaufe ich ihm nicht ab.
    Bei dem fantastischen Wetter heute wollte ich nicht ganz glauben, daß wir nur 995hPa haben sollten und habe mit einer nahegelegenen Wetterstation verglichen und siehe da,
    dort waren es 1022hPa. Der Höhenunterschied kanns nicht sein, dann müsste die Station fast 300m tiefer liegen.
    Auch die Formeln habe ich 10 mal mindestens geprüft. Die sind auch korrekt.
    Vielleicht hat ja jemand das gleiche beobachtet.


    So, für heute solls mal genügen. Wie gesagt, bei Interesse lade ich die Software hoch. Vielleicht kann man ja tatsächlich ein Wetterstations-Projekt aus den Baussteinen machen.


    Gruß
    Odin