Hallo, hat jemand Erfahrungen mit den o.g. Feuchtesensoren? Ich habe einen AM2320 hier, das ist die Version ohne Kabel. Ich habe für meine Zwecke ein Kabel angelötet. Ich konnte nach einigem Tüfteln die Feuchte (und Temperatur) wunderbar per I2C auslesen. Leider scheint sich der Sensor nach einiger Zeit sporadisch aufzuhängen (teilweise nach Minuten oder auch erst nach Stunden). Es kommt dann keine Reaktion mehr, d.h. auch ein I2C-Start schlägt fehl. Erst nach entfernen und neu verbinden des Sensors klappt es wieder. Der Bus ist ok, denn es hängen auch andere Devices daran, die über die ganze Zeit hinweg funktionieren. Als erstes tippte ich auf die (etwas schrägen) Timing-Bedürfnisse des Sensors und habe ein wenig damit experimentiert. Leider löst das das Problem nicht. Durch die Löcher im Gehäuse erkennt man im Sensor eine kleine Platine und Bauteile. Ich kann jedoch nicht erkennen, ob dort ein Kondensator verbaut ist, um die Betriebsspannung zu puffern. Auch das Datenblatt liefert keine Erkenntnisse, ob ein externer Kondensator nötig ist. Vorhin habe ich dem Sensor direkt am Gehäuse einfach mal einen verpasst. Er läuft momentan schon recht lange, aber ich bin noch etwas skeptisch. Meine Frage in die Runde: Habt ihr ähnliches beobachtet? Und wie ist das mit dem AM2315, also der Version mit Kabel? Ist dort ein Kondensator verbaut und wenn nein, wie stabil läuft er?
Mein DHT22 läuft momentan im Kühlschrank sehr stabil schon seit Wochen. Aber: Ich hatte mal den Effekt dass sich der Sensor nach ein paar Stunden scheinbar aufgehangen hat, aber dann habe ich die Auslesezeit auf deutlich über 2 Sekunden (in meinem Fall 5 Sekunden) gesetzt und seitdem läuft es wunderbar. Ich habe den Sensor auch schon im 1s Abstand ausgelesen und es hat auch funktioniert, aber der Sensor braucht ein bisschen Zeit. Als ich es genau alle 2 Sekunden gemacht habe gab es immer nach ein paar Stunden diese Aussetzer und die Temperatur hat sich nicht mehr verändert. Also wirklich deutlich längere Intervalle als 2 Sekunden nutzen!
Hmmm. Also, es war nicht so, dass sich die Werte nicht mehr verändert haben! Nein, der Sensor hat sich komplett tot gestellt. Da kam gar keine Reaktion mehr auf ein Start, bis ich ihn kurz von seiner Betriebsspannung getrennt habe. Mein Experiment mit dem Kondensator hat leider keine Verbesserung gebracht. Ich teste jetzt das Auslesen alle 2,5 Sekunden.
Bruce Forte schrieb: > Nein, der Sensor hat sich komplett tot gestellt. Da kam gar keine > Reaktion mehr auf ein Start, bis ich ihn kurz von seiner > Betriebsspannung getrennt habe. Bei mir war es so dass das Programm genau alle 2 Sekunden neue Werte angefordert hat. Irgendwann habe ich gemerkt dass das Gefrierfach jetzt schon eine Weile nicht mehr anlief. Ich habe dann mit den Tastern die Soll-Temperatur verändert, das resultierte dann darin dass der Sensor in einem größeren Intervall als 2 Sekunden ausgelesen wurde (so lange man den Soll-Wert verändert wird der Sensor nicht ausgelesen) und der Gefrierwürfel nach der Betätigung der Tasten wieder an ging. Der Sensor wurde scheinbar alle 2 Sekunden vom Mikrocontroller "zugemüllt" und konnte seine Aufgabe nicht mehr erledigen, er hätte nur mal für einen Augenblick etwas mehr als 2 Sekunden gebraucht. Da es bei mir hier sehr unkritisch ist habe ich gleich etwas mehr Zeit gegeben. Theoretisch kann ich den Intervall auch leicht auf 60 Sekunden erhöhen.
Hm, ne. Auch mit 2,5-Sekunden-Intervall kackt der Sensor nach einiger Zeit ab. Dann hilft auch eine längere Wartezeit nicht mehr. :(
Hm, ich lese mrinen per arduino-lib alle 2sek. aus. Sicher, dass dein sensor ok ist?
Nun, wie soll ich feststellen, ob der Sensor ok? Die Werte sind plausibel, solange er funktioniert. Bis er irgendwann nicht mehr reagiert.
Bei meinem habe ich an Vcc und GND einen 47µF Elko und zwei mal 4.7µF Kerkos verwendet. Mit welcher Spannung betreibst du deinen DTH22 ? Wenn es mehr als 5V sind oder vielleicht nur 3V, dann ist das möglicher Weise problematisch.
:
Bearbeitet durch User
Laut Datenblatt sollten bis zu 100 kHz I2C-Frequenz möglich sein. Habe sie heute morgen testweise auf 25 kHz gesenkt. Seit 4 Stunden läuft der Sensor jetzt... bin gespannt.
Ich habe einen zweiten Sensor beschafft. Dieser verhält sich genauso. Sensor 1 läuft bei 25 kHz I2C-Frequenz aber weiterhin stabil.
Leider hilft nichts. Egal, was ich probiere, die Sensoren hängen sich beide nach einigen Stunden auf. Das kann doch nicht sein??
Ich habe die kranke 1-Wire-Variante sowohl bei dem AM2302 (der kein I2C kann) und dem AM2320 benutzt, lief testweise tagelang im 1s Raster problemlos. Daher ist vermutlich nur die I2C-Implementierung kaputt. Wer das 1-Wire-Timing entworfen hat, dem traue ich alles zu... Am dem Timing dazu sieht man auch recht deutlich, dass das alles in SW gemacht wird. Nach dem 8ten Bit ist die Pause in der Realität immer 10-20us länger ;)
Angehängte Dateien:
Da ich über ähnliche Phänomene mit 10m Klingeldraht bei 3,3V Versorgung aus einem RasPi gestolpert bin, hier mal meine Lösung, die offenbar funktioniert: Am Anfang der Strippe jetzt 10uF Kerko; am DHT22/AM2302 selber nochmal 0,1+10µF Kerko. Läuft seitdem erstaunlich stabil. Habe irgendwo Gerüchte gelesen, jemand hätte ein Datenblatt gelesen, das 3,3V nur bis 1m Strippe zuließe; ich konnte das jedoch nirgends bestätigt finden. Scheint auch Quatsch, da es jetzt ja zu laufen scheint. Edit: Oh, im AM2320-Datenblatt findet sich ein Hinweis auf Seite 21: http://akizukidenshi.com/download/ds/aosong/AM2320.pdf - da steht es aber eher anders herum, bei <1m sollte man nur 3,3V zur Speisung verwenden.
:
Bearbeitet durch User
nur zur Info: ich habe hier einen AM2321, der läuft seit Monaten bei 3.3V und 100kHz am I2C ohne sich jemals aufgehängt zu haben.
Dirk K. schrieb: > Edit: Oh, im AM2320-Datenblatt findet sich ein Hinweis auf Seite 21: > http://akizukidenshi.com/download/ds/aosong/AM2320.pdf - da steht es > aber eher anders herum, bei <1m sollte man nur 3,3V zur Speisung > verwenden. Mal abgesehen von Megavolt und Megaampere in den DC Characteristics (Table 3) scheinen die etwas eigenwillige Vorstellungen über I2C Pegel und gemischten Betrieb von 3.3V und 5V Komponenten auf einem Bus zu besitzen (Figure 5: I2C typical configuration). Zur Versorgungsspannung steht da doch explizit, dass bei mehr als 1m Länge die 3.3V wegen Spannungsabfällen auf der Leitung zu knapp sein können und es in Folge dessen zu Kommunikationsproblemen kommen kann. Unabhängig von irgenwelchen Schielereien ins Gehäuse, bekommt jede digitale Schaltung einen 100nF Kondensator direkt an den Versorgungspins und fertig. Irgendwelche 47µF||4.7µF-Konstruktionen bringen die Welt nicht wirklich weiter, weil die gegen kurze Spannungseinbrüche durch digitale Schaltflanken nur bedingt helfen.
Muss auch noch mal nachlegen und bestätigen - gerade ist die Kommunikation wieder abgebrochen, man braucht wohl wirklich 5V bei > 1m.
@ Dirk Nimm doch die 1-Wire Variante (die nutze ich auch), die ist doch bestimmt besser für große Entfernungen ausgelegt als die I2C-Version da die Übertragungsgeschwindigkeit viel langsamer ist.
@Mike: Ich hab via 10m Schaltlitze im Bad einen DHT22 aufgehängt, das ist die 1-wire-Variante. Habe heute Morgen auch des Pudels Kern entdeckt. Ich habe die Drähte angelötet und etwas freischwebend gehabt. Das Isotape saß nicht richtig -> Kurzer sowie zwischendrin "harter Pulldown" der Data-Leitung. Jetzt habe ich das Ganze auf etwas Lochraster verbunden, und seitdem nicht das kleinste bisschen Gezicke. Mit den 5V war also vielleicht doch eine Ente. Mein DHT22 als Außensensor hängt mit ~4m Schaltdraht an einem ESP8266 (=3,3V) und zeigt von Anbeginn keine Aussetzer. Merke: Freifliegende Verdrahtung ist Mist. ;)
:
Bearbeitet durch User
Das Aufhängen bei I2C kann ich bestätigen!!!!! Ich will den AM2320 in meine Haussteuerung integrieren und bin da sehr nah an der Hardware. Über die eigenwillige I2C Implementierung ist ja schon geschrieben worden. Bei mir hängt der Sensor mit am Bus und wird alle 8s mit einer Anfrage "aufgeweckt". 55ms später erfolgt dann die Datenübertragung gemäß Datenblatt - auch mit den beiden anderen dort angegebenen Pausen von 1,5ms und 30µs (Seite 15 Figure 14). Letztlich läuft das Ding aber nur Minuten bis Stunden, dann hängt er sich auf und es hilft nur noch Abstöpseln. Also, die Stromversorgung ist es nicht, ich hatte einen Oszi angeschlossen mit Triggerung, wenn VDD am Sensor unter 4,0V fällt - die hat kein einziges Mal angesprochen. Bei Störimpulsen vom Netzteil im Bereich +4,7V..+5V funktionierte diese Testmethode aber ausgezeichnet im einstelligen µs Bereich. Auch hatte ich später 220nF, 47µF und 2 Schottky-Dioden (wegen eventueller negativer Pegel an den Eingängen) ausprobiert, alles Fehlanzeige. Zusätzlich ist mir aufgefallen, dass bei großer kapazitiver Last am Bus der Sensor sich ebenfalls nicht meldet. Möglicherweise ist der starke Bustraffic das Problem - intern bricht ev. die Stromversorgung kurz zusammen und Ende ist. Also eine Designschwäche. Der Ausweg wäre dann nur noch ein zwischengeschalteter ATtiny, der den Sensor "mit Samthandschuhen" anfasst und regelmäßig die Stromversorgung kappt....
Ja, es liegt wohl am Traffic. Wenn nix anderes am Bus hängt, mag es gehen (nicht probiert, weil hier praxisfremd). Ich musste letztlich doch einen Pin opfern und auf 1-wire-Betrieb umsteigen. So geht's jetzt ohne jegliche Probleme. Trotzdem würde ich den Sensor unverblümt als "Schrott" bezeichnen, weil er ja nicht wie beworben läuft.
Ja, "Schrott" ist die richtige Bezeichnung. Leider ist die Auswahl preiswerter Feuchte/Temperatursensoren (die schon kalibriert sind!) nicht sehr gross. Da ich für Klimasteuerungen auch mehrere Sensoren am gleichen Bus betreiben möchte, überlege ich, doch einen ATtiny zwischenzuschalten und mittels Kodierschalter eine Adresse zuzuweisen. Aber wer garantiert, dass der 1-Wirebetrieb auch nach Monaten störungsfrei bleibt? Oder doch 3 Pins (SDA, SCL, +5V) dafür aber einen größeren ATTiny... Ich habe eben noch den letzten Test gestartet: Sensor per I2C auslesen, Trafik für ein paar Stunden einstellen (5V bleiben aber dran) und dann nochmal Traffic einschalten. Sollte es dann noch funktionieren, liegt es wirklich am I2C-Busverkahr. Dann bis heute abend.
AMS2320/DHT22/DHT11 sind alle irgendwie nicht die Bringer. Als Schnellbastelei ok, aber alles außer präzise. WObei, Temperatur können sie alle; Feuchtigkeit jedoch nicht ordentlich. Billig gibt es auch die Si7021, damit tausche ich grad alle DHT22 aus. Wesentlich genauer, ordentlich kalibriert, stabil im Betrieb. Und das Beste, für den Batterie-/Akku-Betrieb auch noch energiesparender. http://www.aliexpress.com/item/Si7021-Industrial-High-Precision-Humidity-Sensor-I2C-Interface/32573472805.html - weniger als 3€ das Stück. Einen Sensor habe ich dann noch mit einem BME280 ersetzt und kann damit sogar den Luftdruck mitschneiden. http://www.aliexpress.com/item/BME280-3-3-I2C-SPI-Digital-Temperature-Humidity-Barometric-Pressure-Altitude-Sensor-ME280-High-Precision-Atmospheric/32574315767.html - 5€ ist ok dafür.
Die Si7021-Board haben einen LDO und Levelshifter onboard. Du kannst die direkt an 5V an einen Arduino klöppeln, oder mit 3,3V betreiben (wie ich es mache). XC6206 (der SOT23-3), der SOT23-6 ist ein Dual-Transistor für den Levelshifter. Die 10kOhm sind u.a. Pullups für I2C. Beim BME280 muss man sich selber drum kümmern.
:
Bearbeitet durch User
So, mein Experiment ist zu Ende. Wie erwartet - 5 ohne Traffic: der Sensor meldet sich prompt wieder. Dann ist aber nach knapp 2 Stunden Schluss. Ursache also Traffic, wie auch immer. Die Alternative Si7021 muss ich mir mal ansehen, vielleicht gehen die für meine Zwecke auch. Wichtig sind ca. 8mA an SDA!
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.