DHT22 gibt manchmal den falschen Wert aus
-
eightball -
15. Dezember 2017 um 20:15 -
Erledigt
-
-
DHT22 gibt manchmal den falschen Wert aus? Schau mal ob du hier fündig wirst!
-
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.)
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.
-
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
-
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
-
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
-
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.
-
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:
Python
Alles anzeigenimport math GRENZWERT_ABWEICHUNG = 0.5 def sim_sensor_eingang(): werte_liste = [] while len(werte_liste) <= 2: wert = input() try: wert = float(wert) except ValueError: print("Nur Zahlen eingeben") werte_liste.append(wert) return werte_liste def calc_durchschnitt(werte_liste): return sum(werte_liste) / len(werte_liste) def check_abweichung(werte_liste, durchschnitt): print("Durchschnitt: {}".format(durchschnitt)) abweichung_ok = True for num, wert in enumerate(werte_liste): delta = wert - durchschnitt delta = math.sqrt(delta**2) if delta <= GRENZWERT_ABWEICHUNG: print("Nummer {} ok, Abweichung beträgt {}".format(num, delta)) else: print("Nummer {} fehlerhaft, Abweichung beträgt {}".format(num, delta)) abweichung_ok = False return abweichung_ok def messwert_nehmen(werte_liste, abweichung_ok): if abweichung_ok: print("Messwert übernommen: {}".format(werte_liste[2])) else: print("Messung muss wiederholt werden") def main(): werte_liste = sim_sensor_eingang() durchschnitt = calc_durchschnitt(werte_liste) abweichung_ok = check_abweichung(werte_liste, durchschnitt) messwert_nehmen(werte_liste, abweichung_ok) if __name__ == "__main__": main()
Inputs:
Ausgabe:
CodeDurchschnitt: 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:
Ausgabe:
CodeDurchschnitt: 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
-
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
-
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!