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.
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.
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 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 ;)
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.
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.
@ 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. ;)
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.
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.
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!
