DHT22 gibt manchmal den falschen Wert aus

  • Hallo zusammen,

    ich hab ein kleines Problem mit meinen beiden DHT22 am RPI3B:

    manchmal gibt er die falsche Temperatur und Luftfeuchte aus, und zwar exakt das doppelte vom realen Wert (siehe Bild).

    Hat jemand eine Idee woran das liegen könnte und wa man dagegen machen kann?

  • Hallo,

    meine Ideen dazu:

    Wiederholst du die Abfrage für den Sensor zu schnell?

    Weitere Idee, Codefehler?

    Ich lass immer 3 mal messen -> Durchschnitt ermitteln -> Abweichung von einzelner Messung zum Durchschnitt --wenn Abweichung kleiner x--> Messung aktzeptieren, ansonsten verwerfen und wiederholen

  • Hallo,

    Danke für deine Antwort.

    Zwischen den Abfragen sind mindestens 10 Sekunden, denke das ist okay.

    Codefehler kann ich mir fast nicht vorstellen, da es ein vorgefertigtes Skript ist (lol_dht22) und bisher eigentlich immer funktioniert hat.

    Zugegebenermaßen habe ich vom Programmieren nur beschränkte Kenntnisse.

  • Ich lass immer 3 mal messen -> Durschnitt ermitteln -> Abweichung von einzelner Messung zum Durschnitt --wenn Abweichung kleiner x--> Messung aktzeptieren, ansonsten verwerfen und wiederholen

    Durchschnitt ist "schlecht", da solche Fehlmessungen wie oben beschrieben, den Durchschnitt stark verfälschen.

    Ich verwende 5-7 Messungen und bilde den Median (Liste sortieren, den mittleren Wert nehmen, damit fallen (stark) abweichende Messwerte raus..

    (Bzw.: nach Medianbildung den Durchschnitt über die mittleren Werte bilden, also bei 5 oder 7 Werten über die 3 mittleren.)

    eightball :

    Das die DHT-Sensoren ab und zu mal "spinnen" scheint Teil des Messprinzips zu sein ;-), haben viele...

    Auch wichtig: den 1-2k Widerstand unmittelbar am Gehäuse anbringen (siehe Standardbeschaltung der DHT's).

  • Klingt irgendwie nach einem um 1 Bit verschobenen Wert. Irgendein Problem bei der seriellen Übertragung - wird vielleicht ein Bit verschluckt und alle anderen verschieben sich dann ums eins. Timing-Problem oder unsaubere Flanken, die bei der Synchronisation stören. Wenn es sowas ist, wird aber offenbar immer das erste Bit verschluckt - also direkt nach dem Response-Signal. Das Prüfbyte ist die Addition der vier Einzelbytes - und wird ebenfalls verschoben, also verdoppelt - stimmt dann also noch.

    Probier mal eine andere Verkabelung, kürzere Kabel, andere Widerstände oder was immer du in der Schaltung hast. Ist die Spannungsversorgung stabil?

    Kannst du das Signal mal direkt erfassen - vielleicht mit einer schnellen Schleife den GPIO abfragen und schauen, wie das Timing ist. Ein Oszi hast du sicher nicht.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Das die DHT-Sensoren ab und zu mal "spinnen" scheint Teil des Messprinzips zu sein ;-), haben viele...

    was mache ich falsch?

    ich habe noch nie eine Falschmessung an meinem Arduino gesehen, ich messe aber nur alle 15 Sekunden

    Spoiler anzeigen

    Sa 16.Dez 2017

    01:38:45 Uhr R

    DTH H= 30.2%

    DHT T= 23.5*C

    RTC T= 23,5*C

    con=63 hell=07

    Sa 16.Dez 2017

    01:39:00 Uhr R

    DTH H= 30.2%

    DHT T= 23.5*C

    RTC T= 23,5*C

    con=63 hell=07

    Sa 16.Dez 2017

    01:39:15 Uhr R

    DTH H= 30.1%

    DHT T= 23.5*C

    RTC T= 23,5*C

    con=63 hell=07

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hi jar,

    hm, jetzt, wo Du es ansprichst. Geht mir auch so. Bei allen Sensoren und mehrfüßigen Bauteilen, die ich bislang angesteuert und ausgelesen habe, habe ich mich stur an die Protokollbeschreibungen der Datenblätter orientiert. "Fertige" Programme oder Libraries habe ich nie verwendet. Ich habe aber auch noch nie Auslesefehler erhalten. Ich habe mir aber wirklich alle Mühe gegeben.


    eightball: Ich hatte hier vor kurzem ein älteres Tutorial zum Auslesen des DHT22 eingestellt. Das hatte ich mal für jemanden erstellt, ist dann aber irgendwie verschütt gegangen. Jahre später ... und so ...

    Wenn Du Dir dieses Tutorial oder das Datenblatt zum DHT11 / DHT22 durchliest, dann stellst Du fest, dass diese beiden Sensoren recht hohe Ansprüche bzgl. des Timings stellen. Meiner Meinung nach geht das sehr grenzwertig in Richtung "Echtzeit-Betriebssystem". Ob das der Raspberry Pi immer so hinbekommt, möchte ich bezweifeln, insbesondere dann, wenn noch andere Programme und insbesondere Dienste verrichtet werden sollen. Dann bleibt mal das eine oder andere Bit oder auch mehr "hängen" - oder wird keine Trennung zwischen den Bits erkannt oder ... oder ...

    Solche Probleme gibt's beim Arduino systembedingt schon mal gar nicht.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Meiner Meinung nach geht das sehr grenzwertig in Richtung "Echtzeit-Betriebssystem". Ob das der Raspberry Pi immer so hinbekommt, möchte ich bezweifeln,

    Solche Probleme gibt's beim Arduino systembedingt schon mal gar nicht.

    sehe ich genauso, am PI Timing einhalten IMHO unmöglich

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • was mache ich falsch?

    ich habe noch nie eine Falschmessung an meinem Arduino gesehen, ich messe aber nur alle 15 Sekunden

    jar & Andreas : schön, aber mit "works for me" - Aussagen ist keinem geholfen...

    Ich habe hier drei (3) DHT22 bzw. deren Äquivalentteile AM... im Einsatz, einen an einem RasPi und zwei an ESP's (ESP8266).

    ALLE haben das gleiche, wie beim TO geschilderte Problem, dass sporadisch die Auslesewerte "wrong" sind, obwohl die CRC als gültig verifiziert wird.

    Die Stromversorgung ist bei den an die ESPs angeschlossenen Teilen (direkt am Sensor) mit Elkos und Keramic-C's geblockt, bei dem am RasPi (3m Kabel zum Sensor) nur per Keramic-C... Alle werden "normal" versorgt (keine Phantom-Speisung)...

    Dass lässt m.E. auf einen internen Umsetzungsfehler schliessen.

    Wo da die Ursache zu suchen ist (Spanungsversorgung? Störfelder? Bauteiltoleranzen?) ist unklar, möglicherweise sind das Serienfehler und der Grund dafür, warum man diese Bauteile so billig bekommen hat ...

    (OT: Bei den Wäägebalkenumsetzer HX711 habe ich in einem anderen Beitrag die mangelhafte Temperaturstabilität beschrieben, welche lt. Datenblatt kompensiert sein soll, bei den Chips, die ich habe aber nicht funktioniert... - vermutlich gleiches Thema.. /OT)

    Timingprobleme? Die ESP's sollten hier keine haben, die langweilen sich... Meine Ausleseabstände liegen bei 5 bzw 10min.

    Wie in meinem letzten Beitrag geschildert, habe ich das Problem mittels Mehrfachmessung und anschließendem Median behandelt.

  • Wie in meinem letzten Beitrag geschildert, habe ich das Problem mittels Mehrfachmessung und anschließendem Median behandelt.


    ist ja völlig legitim und eine gute Lösung für alle Falschmessung geplagten.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Durchschnitt ist "schlecht", da solche Fehlmessungen wie oben beschrieben, den Durchschnitt stark verfälschen.

    Huhu Zentris, ich schrieb auch nicht dass ich den Durchschnitt verwende ;)

    Ich lass immer 3 mal messen -> Durschnitt ermitteln -> Abweichung von einzelner Messung zum Durschnitt --wenn Abweichung kleiner x--> Messung aktzeptieren,

    Ich hab das ganze mal in einen Beispielcode gegossen zur besseren Verständnis wie ich das meinte:

    Inputs:

    Code
    10
    11
    10.1

    Ausgabe:

    Code
    Durchschnitt: 10.366666666666667
    Nummer 0 ok, Abweichung beträgt 0.36666666666666714
    Nummer 1 fehlerhaft, Abweichung beträgt 0.6333333333333329
    Nummer 2 ok, Abweichung beträgt 0.2666666666666675
    Messung muss wiederholt werden

    Neuer Lauf

    Inputs:

    Code
    10
    10.3
    10.2

    Ausgabe:

    Code
    Durchschnitt: 10.166666666666666
    Nummer 0 ok, Abweichung beträgt 0.16666666666666607
    Nummer 1 ok, Abweichung beträgt 0.13333333333333464
    Nummer 2 ok, Abweichung beträgt 0.033333333333333215
    Messwert übernommen: 10.2

    Hoffe es wird das oben zitierte nun besser verstanden wie ich das meinte.

    Median kann man natürlich auch machen, meines ist eine Abwandlung in Anlehnung der Standardabweichung^^

  • Hallo zusammen,

    was noch sinnvoll ist:

    - mehrere Messwerte aufnehmen

    - Messwerte sortieren

    - Ausreißertests (z.B. nach Grubbs) durchführen

    - mit den Ausreißer-freien Messwerten Mittelwert ermitteln - oder Median Zentris ;)


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Huhu Zentris, ich schrieb auch nicht dass ich den Durschnitt verwende ;)

    Ich will ja nicht streiten :) aber:

    DOCH, du hast (eigenartige Schreibweise) "Durschnitt" geschrieben... und dass du ihn verwendest...

    Siehe auch dein 1. Post bzw. mein Post #4.

    Deine weiteren Ausführungen beschreiben (nur) die Ausführung eines bewerteten Durchschnitts hinsichtlich der Abweichung der einzelnen Messwerte vom berechneten Durchschnitt.

    Das ist durchaus legitim (!) und "kann man so machen" :) führt jedoch zu anderen Problemen (gerade bei einer größeren Anzahl von "Fehlmessungen":

    * Wieviel % der Messungen dürfen "wrong" sein?

    * Werden dann alle Messungen wiederholt oder nur die Anzahl der "schlechten" ?

    Bei zeitlich variablen Messwerten und langsamen Messumsetzern (Sensoren), wie z.B. der DS18B20 einer ist, entfernt man sich u.U. immer weiter vom eigentlichen Messzeitpunkt und die gesamte Messung ist "für die Tonne"...

    [OT]: (jetzt fang ich schon an wie Andreas *lol* )

    Ich habe hier ein Gerät (Heizkreisreglung), da muss ich "zeitgleich" (wegen eines hintergeschalteten PIR-Reglers) Temperaturen an 3 verschiedenen Messpunkten aufnehmen. Sensoren sind DS18B20...

    Zum einen werden die "quasi"-Synchron gestartet und messen 5 mal hintereinander... pro Sensor dauert das dann ca. 6sec.

    Verwendet wird der per Median ermittelt Wert... eine wiederholte Messreihe eines einzelnen Sensors wäre fatal für die Regelung...

    Das System ist zwar "langsam" (thermisch träge) ... aber gerade in der (kritischen) Aufheizphase recht flink... ca. 10-15k/min

    [/OT]

    ;)

  • Ich schrieb Durchschnitt ermitteln, nicht verwenden ;) kleiner aber feiner Unterschied

    Im restlichen wirst du wohl schon mehr Erfahrung sammeln dürfen wie ich (Messfehler und Messabweichung) - ob da jetzt der Median besser geeignet ist oder nicht mag ich nicht beurteilen^^

  • Hallo Hofei,

    der Median ist eine feine Sache, da er sich bei zeitkritischen Vorhaben schnell ermitteln lässt.

    Angeregt durch diesen Thread programmiere ich gerade was zum Thema "Ausreißertest". Nach der Methode von Grubbs wird nur mit dem Median gearbeitet. Auch für die Quartile, innere und äußere Zäune... um milde und extreme Ausreißer zu identifizieren.

    Bei so wenigen Messwerten, wie sie in diesem Thread erforderlich sind, braucht man das aber alles nicht. Sobald Du 5 oder 7 Messwerte gezogen hast, ist der Median hinreichend genau.

    Die harten statistischen Tests auf Normalverteilung greifen bei so geringer Messwertanzahl eh nicht.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (16. Dezember 2017 um 22:45)

  • Hallo eightball

    Ich habe mit dem Median nur gute Erfahrungen gemacht.

    Dazu verwende ich ein Datenfeld mit einer ungeraden Anzahl von Elementen. Immer wenn ein neuer Messwert anliegt, verwerfe ich den ältesten Messwert des Datenfeldes und speichere auf dessen Speicherstelle den neuen Messwert. Danach speichere ich das Datenfeld auf ein zweites um und sortiere dort die Messwerte. Der Median des sortierten Feldes wird dann als aktueller Messwert weiterverarbeitet. Mit jedem neuen Messwert ein neuer Median. Funktioniert für verrauschte Signale wunderbar.

    Bei Interesse kann ich den C-Code dazu liefern.

    Für Temperatur und Feuchte den doppelten Wert ist erfahrungsgemäß kein Verkabelungsfehler. Das scheint eher ein Zeitproblem zu sein.

    Der RPI3B hat doch vier Cores. Kannst Du einmal versuchen Deine Messwerterfassung einem Core zuzuordnen und alle anderen Prozesse den restlichen drei Cores ?

    Auf diese Art kann ich mit einem RPI3B einen Sensor auslesen, welcher den Messwert als Frequenzsignal ausgibt. Die Ausgangsfrequenz über den Messbereich ist dabei 0 .. 20 kHz. Da geht keine Flanke verloren. Den C-Code für die Verlagerung aller anderen Prozesse auf die anderen drei Cores kann ich bei Interesse auch zur Verfügung stellen. Zur Not kann man das für einen Test vorab auch "zu Fuß" über die Konsole ausprobieren, zumindest für die "Schwergewichte".

    Gruß

    Prittzl

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!