Guten Abend, ich habe mir DHT22 Temperatur/Luftfeutigkeits Sensoren besorgt mit 1-Wire Interface. Datenblatt im Anhang. Ich nutze einen Atmega328P und Microchip Studio. Es gibt verschiedene Bibliotheken im Internet um den Sensor anzusteuern. Im Anhang mal die Pegel der Leitung aufgezeichnet. Die Probleme fangen schon mit der Startsequenz (Datenblatt Seite 4) an. Es soll der Bus zwischen 1 und 18 ms auf low gezogen werden. Mit 1 - 2 ms langen Pulsen reagiert der Sensor, sonst nicht. Ich ziehe den Bus also 2 ms auf low. Laut Datenblatt soll dann 20 - 40 us high folgen und abgewartet werden. Man sieht im Anhang, dass dies nur wenige Mikrosekunden sind, in diesem Fall 3 us. Das ganze ändert sich je nach dem wie lange ich zuvor low gehalten habe. Anschließend soll vom Sensor 80 us low und 80 us high folgen und dann kann man 40 bits auslesen. Diese 80 us los und 80 us high existieren nicht. Die Bit soll man auslesen, in dem man die high länge misst (26-28 us high = 0, 70 us high = 1) Die Bits sehen an sich okey aus, wobei Ungenauigkeiten von 5 us auftreten. Jetzt stellen sich mir folgende Fragen: Habe ich ein falsches Datenblatt oder ist der Sensor einfach nur Müll? Wie bekommen andere sowas zuverlässig ans laufen? Keine der von mir runtergeladenen Libraries funktioniert und man bekommt sofort Timeout Errors, weil der Sensor gefühlt tut was er will, gerade bei der Startsequenz. Ich habe kein Problem damit das Protokoll anzupassen aber mir stellt sich zusätzlich die Frage wie genau dieser angeblich kalibrierter Sensor ist, wenn nicht mal die Startsequenz nach Datenblatt arbeitet.
Angehängte Dateien:
-
GesamteKommunikation.JPG
120 KB -
StartSignal.JPG
110 KB
Sef C. schrieb: > Ich nutze einen Atmega328P auch Abblock Kondensatoren (VCC-GND)? wie groß ist der pullup an Data, wie lang die Leitungen?
Joachim B. schrieb: > auch Abblock Kondensatoren (VCC-GND)? > wie groß ist der pullup an Data, wie lang die Leitungen? Flying-Wire Verdrahtung mit hübschen 10 cm Leitungen :P Pull-up 4.7k. Die Bits kommen ja ganz okey daher mit ein paar us Fehler, deswegen glaube ich nicht das ein direkter Abblockkondensator da irgendwas rettet.
:
Bearbeitet durch User
Sef C. schrieb: > Man sieht im Anhang Hast du das Signal auch mal mit dem Oszi angeschaut? Sieht das ordentlich aus? Hast du stetige Flanken ohne "Stufen" darin? Ist die steigende Flanke "steil" genug? Da gibts noch mehr dieser eigenartigen Datenblätter, die zwar hübsch grafisch aufbereitet sind, aber keine bruachbaren Timing-Spezifikationen mit min. und max. Werten beinhalten: https://www.mikrocontroller-elektronik.de/dht22-am2302-luftfeuchte-und-temperatursensor/ Das Protokoll hinter diesen Dingern ist übrigens an das Onewire-Protokoll (1-wire) angelehnt. Wer die Dinger ans Laufen bekommt, hat sicher schon mal von diesem Protokoll der Fa. Dallas gehört
Joachim B. schrieb: > auch Abblock Kondensatoren (VCC-GND)? ...falls du den uC meintest, das ist ein Arduino Nano auf Breakout-Board mit entsprechenden Kondensatoren.
Lothar M. schrieb: > Da gibts noch mehr dieser eigenartigen Datenblätter, die zwar hübsch > grafisch aufbereitet sind, aber keine bruachbaren Timing-Spezifikationen > mit min. und max. Werten beinhalten: > https://www.mikrocontroller-elektronik.de/dht22-am2302-luftfeuchte-und-temperatursensor/ Die Timings sind in den unterschiedlichen Datenblättern die ich gesichtet haben gleich gewesen.
Sef C. schrieb: > ich habe mir DHT22 Temperatur/Luftfeutigkeits Sensoren besorgt mit > 1-Wire Interface Die haben kein 1-Wire Interface, jedenfalls nicht das, was unter der Bezeichnung "1-Wire" von Dallas eingeführt wurde. https://de.wikipedia.org/wiki/1-Wire
Ich habe hier so ein Teil an einem Wemos mit der Adafruit DHT sensor library 1.4.2 (https://github.com/adafruit/DHT-sensor-library)laufen. Kompiliert mit der Arduino IDE, ging out of the box. Vielleicht ist das Teil defekt?
Vielleicht nimmst dir besser einen anderen Sensor (BME280 zB). Ich habe mit dem DHT22 die Erfahrung gemacht, dass die Werte zwar ok sind, der jedoch relativ schnell kaputt ist. Im Netz liest man auch davon; ein Freund von mir hat das Problem ebenfalls (bleibt aber aus Faulheit tapfer beim DHT22). Nachteil ist aktuell nur, dass BME280 schwerer zu kriegen und daher vergleichsweise teuer sind.
Torsten schrieb: > Vielleicht nimmst dir besser einen anderen Sensor (BME280 zB). Ich > habe > mit dem DHT22 die Erfahrung gemacht, dass die Werte zwar ok sind, der > jedoch relativ schnell kaputt ist. Im Netz liest man auch davon; ein > Freund von mir hat das Problem ebenfalls (bleibt aber aus Faulheit > tapfer beim DHT22). Solange man die Sensoren im Innenraum nutzt, sollten sie eigentlich halten. Ich habe einige DHT22 im Keller seit mindestens 5 Jahren und noch keinen Ausfall. Im Außenbereich sind sie schnell hinüber, wenn man sie nicht vor Wasser und gesättigter Luft, Nebel etc. schützt. Das betrifft aber genauso die BME-Sensoren, aus eigener Erfahrung. Der größte Nachteil der DHT-Teile ist die nicht vorhandene Adressierbarkeit wie beim richtigen 1-wire, d.h. man braucht für jeden Sensor einen eignen Datenpin am AVR.
Angehängte Dateien:
Jens H. schrieb: > Vielleicht ist das > Teil defekt? Nein, habe gerade den 2ten aus der Verpackung gezogen und der verhält sich genauso. Torsten schrieb: > Vielleicht nimmst dir besser einen anderen Sensor (BME280 zB). Ja, vielleicht. Nervt aber hart das man angeblich funktionierende und vielseitig genutzte Sensoren kauft und die Dinger nur Schrott machen. Anbei nochmal die Bus Pegel für ein Startsignal für 1 ms auf Low. Dann findet man die zwei 80 us Pulse, aber nicht die 20-40 us nach dem Startsignal. Richtig nervig sowas! Gekauft habe ich die Sensoren beim Makershop, also nicht mal ein China Händler. Dort steht auf der Seite "(DHT22 – Neuste, überarbeitete Version aus 2021 Aosong/ASAIR Produktion)". Könnte es hier eine Timingänderung gegeben haben? Ich schreibe Makershop mal eine Email...
Ohne deinen Code geht es wohl nicht weiter. Man vertut sich bei diesen Datenblättern gerne damit, wer wann welchen Pegel erzeugt. Die 20-40 µs müssen vom host erzeugt werden. Deine 3 µs scheinen vom sensor erzeugt worden zu sein.
Lutz schrieb: > Ohne deinen Code geht es wohl nicht weiter. Man vertut sich bei diesen > Datenblättern gerne damit, wer wann welchen Pegel erzeugt. Die 20-40 > µs müssen vom host erzeugt werden. Deine 3 µs scheinen vom sensor > erzeugt worden zu sein. Hast du absolut recht und habe ich gerade eben getestet. Wenn der Host die 20-40 us auf high zieht schickt der Sensor nicht mal vernünftig die Bits raus und es geht gar nichts. Hier mal ein Auszug aus einer Bibliothek die ich im Internet gefunden habe. Man sieht, dass auch hier der Port auf Input mit Pullup steht für die 20-40 us Sequenz:
1 | //reset port
|
2 | DHT_DDR |= (1<<DHT_INPUTPIN); //output |
3 | DHT_PORT |= (1<<DHT_INPUTPIN); //high |
4 | _delay_ms(100); |
5 | |
6 | //send request
|
7 | DHT_PORT &= ~(1<<DHT_INPUTPIN); //low |
8 | #if DHT_TYPE == DHT_DHT11
|
9 | _delay_ms(18); |
10 | #elif DHT_TYPE == DHT_DHT22
|
11 | _delay_us(500); |
12 | #endif
|
13 | DHT_PORT |= (1<<DHT_INPUTPIN); //high |
14 | DHT_DDR &= ~(1<<DHT_INPUTPIN); //input |
15 | _delay_us(40); |
16 | |
17 | //check start condition 1
|
18 | if((DHT_PIN & (1<<DHT_INPUTPIN))) { |
19 | return -1; |
20 | }
|
21 | _delay_us(80); |
22 | //check start condition 2
|
23 | if(!(DHT_PIN & (1<<DHT_INPUTPIN))) { |
24 | return -1; |
25 | }
|
26 | _delay_us(80); |
27 | |
28 | //read the data
|
29 | uint16_t timeoutcounter = 0; |
30 | for (j=0; j<5; j++) { //read 5 byte |
31 | uint8_t result=0; |
32 | for(i=0; i<8; i++) {//read every bit |
33 | timeoutcounter = 0; |
34 | while(!(DHT_PIN & (1<<DHT_INPUTPIN))) { //wait for an high input (non blocking) |
35 | timeoutcounter++; |
36 | if(timeoutcounter > DHT_TIMEOUT) { |
37 | return -1; //timeout |
38 | }
|
39 | }
|
40 | _delay_us(30); |
41 | if(DHT_PIN & (1<<DHT_INPUTPIN)) //if input is high after 30 us, get result |
42 | result |= (1<<(7-i)); |
43 | timeoutcounter = 0; |
44 | while(DHT_PIN & (1<<DHT_INPUTPIN)) { //wait until input get low (non blocking) |
45 | timeoutcounter++; |
46 | if(timeoutcounter > DHT_TIMEOUT) { |
47 | return -1; //timeout |
48 | }
|
49 | }
|
50 | }
|
51 | bits[j] = result; |
52 | }
|
53 | |
54 | //reset port
|
55 | DHT_DDR |= (1<<DHT_INPUTPIN); //output |
56 | DHT_PORT |= (1<<DHT_INPUTPIN); //low |
57 | _delay_ms(100); |
Ich schreibe mir gerade meinen eigenen Treiber. Ich hoffe nur das bei schwankender Versorgungsspannung (Batteriebetrieb) nicht alle Timings wieder hinfällig sind die ich messe, weil dann hat der Sensor eindeutig den Retourenaufkleber gewonnen.
:
Bearbeitet durch User
Wobei
1 | #elif DHT_TYPE == DHT_DHT22
|
2 | _delay_us(500); |
auch schon dem Datenblatt widerspricht. Das fordert mindestens 1.000 µs low.
Lutz schrieb: > Wobei #elif DHT_TYPE == DHT_DHT22 > _delay_us(500); > auch schon dem Datenblatt widerspricht. Das fordert mindestens 1.000 µs > low. Ja, damit klappt es auch nicht. Es müssen tatsächlich mind. 1000 us sein. Zeigt das auch schon andere mit dem Sensor zu kämpfen hatten.
:
Bearbeitet durch User
Bekomme jetzt Daten aus dem Ding raus...es zeigt mir eine aktuelle Raumtemperatur von 25.3° an. Daneben steht eine Wetterstation die der Meinung ist es wären hier 22.4°. Meine Füße sind leicht kühl und bestätigen die Messung der Wetterstation. Ich schicke die DHT22 zurück und kann hiermit nur jedem von diesen Sensoren abraten. 3 Stück haben mich 15€ gekostet. Gekauft habe ich sie nur, weil sie hier aufgeführt sind und die Performance überzeugt hat: https://www.mikrocontroller.net/articles/Temperatursensor Tatsächlich sollte man den Sensor auf dieser Seite mal als Müll deklarieren. Kann jemand (neben dem BME280) eine Empfehlung für einen günstigen Sensor aussprechen der gut funktioniert?
:
Bearbeitet durch User
Sef C. schrieb: > Tatsächlich sollte man den Sensor auf dieser Seite mal als Müll > deklarieren. Du meinst deine konkreten Produkte. Aus China bekommst du unterschiedliche Produkte unter gleichem Namen und gleiche Produkte unter unterschiedlichen Namen. Schon der nächste Kauf könnte ein Glückstreffer sein.
Sef C. schrieb: > Meine Füße sind leicht kühl und bestätigen die Messung der Wetterstation. Ein ganz neuer Ansatz zur Feststellung der Validität ;-)
my2ct schrieb: > Sef C. schrieb: >> ich habe mir DHT22 Temperatur/Luftfeutigkeits Sensoren besorgt mit >> 1-Wire Interface > > Die haben kein 1-Wire Interface, jedenfalls nicht das, was unter der > Bezeichnung "1-Wire" von Dallas eingeführt wurde. > https://de.wikipedia.org/wiki/1-Wire Das steht sogar im oben verlinkten Datenblatt ... Sef C. schrieb: > Bekomme jetzt Daten aus dem Ding raus...es zeigt mir eine aktuelle Aha - und was hast du jetzt anders gemacht, damit plötzlich was kommt? Sef C. schrieb: > Die Probleme fangen schon mit der Startsequenz (Datenblatt Seite 4) an. Wie sieht denn die Startsequenz aus, wenn Du gar keinen Sensor anschließt (also praktisch nur der PullUp-R dran)? Einfach nur, um zu sehen, ob die 3µs durch den Sensor oder den µC begrenzt werden ...
Stefan ⛄ F. schrieb: > Aus China bekommst du unterschiedliche Produkte unter gleichem Namen und > gleiche Produkte unter unterschiedlichen Namen. Ich habe den Sensor nicht bei einem billig China-Händler erworben. Ich glaube auch nicht, dass ich eine Sensor-Kopie habe bei der man sich überlegt hat dass die Startsequenz doch vielleicht mal anders aussehen könnte...die Bits kommen ja korrekt raus. Jens G. schrieb: > Aha - und was hast du jetzt anders gemacht, damit plötzlich was kommt? Habe ich doch alles hier schon erklärt: Ich habe die Timings so angepasst das sie den gemessenen Timings entsprechen. Jens G. schrieb: > Wie sieht denn die Startsequenz aus, wenn Du gar keinen Sensor > anschließt (also praktisch nur der PullUp-R dran)? Einfach nur, um zu > sehen, ob die 3µs durch den Sensor oder den µC begrenzt werden ... Welchen Zweck soll dieser Test haben? Wenn ich gar keinen Sensor anschließe wird der Bus für 1 ms auf low gezogen und das war es. Ich habe bereits oben schon gesagt, dass der Sensor nach 3 us den Bus von high auf low zieht. Nach den 1 ms wird der Port auf Input gesetzt.
:
Bearbeitet durch User
Sef C. schrieb: > Ich habe den Sensor nicht bei einem billig China-Händler erworben. Das ändert leider nichts daran, dass es so ein typisches China-Produkt ist. Deine Erfahrung musste ich sogar beim teuren Conrad machen. Ein Tipp fürs nächste mal: Bevor du ein Produkt kaufst schau nach, ob es bei Aliexpress deutlich billiger angeboten wird. Wenn ja, dann ist es so ein Produkt. Ausnahme sind gefälschte Markenprodukte: DS1820, Echtzeituhren, STM32F103, Akkus, große Transistoren
Stefan ⛄ F. schrieb: > Aus China bekommst du unterschiedliche Produkte unter gleichem Namen und > gleiche Produkte unter unterschiedlichen Namen. > > Schon der nächste Kauf könnte ein Glückstreffer sein. das passiert auch aus D, was denkst du wo deutsche Händler einkaufen!
Joachim B. schrieb: > das passiert auch aus D, was denkst du wo deutsche Händler einkaufen! Ja stimmt. Sogar Conrad verkauft einige dieser "China Produkte".
Stefan ⛄ F. schrieb: > Ausnahme sind gefälschte Markenprodukte: DS1820, Echtzeituhren, > STM32F103, Akkus, große Transistoren Apropos DS18B20, echte gibt es bei Pollin oder Reichelt, allerdings nun schon für über 5 € pro Stück. Hammer! Oder, man kauft sich ein Entwicklerboard für 2.40 € und lötet sich den Sensor aus. Vor einigen Monaten habe ich die Teile noch für 2 € beim Pollin gekauft. Beim Ali gab es früher(TM) auch noch echte. Meine letzte Bestellung waren aber auch Fakes und es hat einigen Disput gebraucht, bis ich mein Geld wieder hatte.
Jens H. schrieb: > Apropos DS18B20, echte gibt es bei Pollin oder Reichelt, allerdings nun > schon für über 5 € pro Stück. Hammer! Oder, man kauft sich ein > Entwicklerboard für 2.40 € und lötet sich den Sensor aus. Vor einigen > Monaten habe ich die Teile noch für 2 € beim Pollin gekauft. Beim Ali > gab es früher(TM) auch noch echte. Meine letzte Bestellung waren aber > auch Fakes und es hat einigen Disput gebraucht, bis ich mein Geld wieder > hatte. Jetzt mal ernsthaft: Wer klaut wo das Know-How für Halbleiterbauelemente und stellt diese dann so her, dass sie teilweise funktionieren und teilweise halt ein bisschen anders oder gar nicht. Halbleitertechnik macht man nicht mal eben im Bastelkeller und ist so aufwändig, dass man wissen muss was man tut. Wie kann da bitte, wie in diesem Beispiel hier, ein Bauteil rausfallen das Bits richtig rausshiftet aber ansonsten seine Startsequenz gewürfelt hat. Ich kann das irgendwie nicht glauben...
Sef C. schrieb: > Wer klaut wo das Know-How für Halbleiterbauelemente > und stellt diese dann so her, dass sie teilweise funktionieren und > teilweise halt ein bisschen anders oder gar nicht. In China ist das alltäglich. Schau dir doch mal die Berichte zu den STM32F103 Nachbauten und Fälschungen an.
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.