der Sensor HDC1080 sitzt auf einem China-Modul. Laut Datenblatt sind 2.7-5.5V möglich. Versorgt wird er über Arduino-nano3 per USB. Die Spannung liegt also etwas über 4V. Angesprochen wird per I2C mit ~400kHz. Als Auflösung ist 14bit gewählt. Die Messung wird gestartet und per delay 7ms gewartet. Laut Datenblatt sollte dann ein brauchbarer Wert vorliegen. Der 14bit Wert wird über 2 byte ausgelesen und diese je 2 bit rechtsverschoben in ein unsigned int gesteckt. Es wird dann skaliert so daß bei 100% Feuchte 10000 geliefert wird. So ergeben sich 2 Stellen hinter dem Komma. Es ist auffallend daß bei 14bit Auflösung der Sensor keine stabilen Werte liefert. Es kommen meist einige Werte scheinbar stabil und dann ein Sprung zu anderen Werten. Die Sprünge liegen bei ~0.1% Feuchte. Das sind also weit größere Sprünge als mit 14bit Auflösung zu erwarten wären: - Bei 8bit wäre 1 LSB ~0.4%. - Bei 9bit würde man ~0.2% erwarten. - Bei 10bit wären es ~0.1%, - bei 11bit ~0.05%, - bei 12bit ~0.025%, - bei 13bit ~0.0125%. Es werden also bei 14bit nur ~10bit brauchbare Auflösung erreicht. Kennt jemand dieses Phänomen? Sind die chips aus China Ausreißer und Originale von TI viel besser?
Liegt doch gut... Laut Datenblatt: "Relative Humidity Accuracy ±2% (typical)" Also bei 0,1% ... Ich weiß nicht was du eigentlich erwartest? Mir ist auch nicht bekannt das es so genaue Hum-Sensoren gibt. Desweiteren, verstehe ich nicht warum du ihn so schnell abfragst, die Response-Time liegt bei 15s. Nur weil die Conversion-Time ~7ms braucht heißt das noch lange nicht das dies auch Sinn macht, ganz im Gegenteil. Ich denke du berechnest mit der Membran-Temperatur über den Tempsensor? Matthias W. schrieb: > Die > Spannung liegt also etwas über 4V. Ist natürlich machbar und tolerant, aber halt unter Table 7.3. VDD - NOM 3V.
:
Bearbeitet durch User
Matthias W. schrieb: > nur ~10bit brauchbare Auflösung es ist ein großer Unterschied zwischen Auflösung und Genauigkeit. Die Genauigkeit ist angebenen. Dazu gibt es ein Diagramm. Ob diese Absolutwerte im %-Bereich eingehalten werden kann ich mangels Vergleich nicht sagen. Hier jedoch ist die Auflösung gefragt. Da sollte man doch erwarten können daß sich die Feuchte im normalen Zimmer recht langsam ändert. Es sollte die Feuchte-Anzeige bei Auslesung alle 7ms daher nicht in größeren Stufen springen, sonst ist diese Auflösung schlicht Unsinn. Warum bietet der Hersteller die Wahl von 14bit Auflösung an, wenn in der Praxis nur 10bit Auflösung zu sehen sind? Selbst die wählbare 11bit Auflösung sehe ich momentan nicht. Das Verhalten mit reihenweise konstanten Werten und dann großen Sprüngen im Bereich 10bit-Auflösung erscheint unplausibel.
Rene K. schrieb: > "Relative Humidity Accuracy ±2% (typical)" > Also bei 0,1% Danke Rene für den Beitrag ! die Genauigkeit von 2% bei ~60% Anzeige habe ich nicht geprüft. Die 0.1% sind die sichtbare Auflösung. Diese sollte jedoch laut Datenblatt bei 14bit liegen und nicht bei 10bit.
Wenn du alle 7ms abfragst, erhitzt sich das PCB... Nicht viel, aber für das Membran immer ein Faktor, deswegen gibt es die Temperaturkompensation. Nutzt du sie oder nutzt du sie nicht? Die Hysterese, die du ansprichst liegt bei diesem Sensor ebenfalls bei +/- 1%. Deine Werte machen alle Sinn, keine Angst. Versuche einfach mal deinen Sensor langsamer abzufragen. Lass ihn mal 100ms... Du bist schlicht und ergreifend zu schnell.
Rene K. schrieb: > Ich denke du berechnest mit der Membran-Temperatur über den Tempsensor? Den Temperatursensor habe ich bisher nicht ausgelesen. Im Chip ist auch ein OTP-Speicher der temperaturabhängig die Feuchte korrigiert. Dies kann ich nicht beeinflussen. Es ist so daß rasches Auslesen der Werte zu mehr mittlerem Stromverbrauch und somit zu einer kleinen Eigenerwärmung führt. Dies könnte ggf. zu Fehlern führen. Es ist jedoch so daß der Strombedarf im uA-Bereich liegt. Da sollte die Eigenerwärmung klein sein und der Fehler somit dank der eingebauten Temperaturkompensation auch.
Rene K. schrieb: > deswegen gibt es die > Temperaturkompensation. Nutzt du sie oder nutzt du sie nicht? diese arbeitet doch automatisch? Ich kenne beim HDC1080 kein Register um diese zu ein- oder abzuschalten. Ich kenne auch keine Rechenvorschrift für eine darüber hinausgehende Kompensation der Feuchte.
Rene K. schrieb: > Die Hysterese, die du ansprichst liegt bei diesem Sensor ebenfalls bei > +/- 1%. das klingt so als ob erst ~1% Änderung nötig ist um den Wert zu ändern. Was bringt dann eine Auflösung von 14bit? Mir erschließt sich der Sinn da nicht.
Matthias W. schrieb: > Im Chip ist auch > ein OTP-Speicher der temperaturabhängig die Feuchte korrigiert. Uh uh... Vorsicht! Im OTP liegen die Factory Calibrations. Das hat meiner Meinung nach nichts mit der Temperaturkompensation zur Laufzeitmessung zu tun. Wo ließt du dies denn im DB? Matthias W. schrieb: > Es ist so daß rasches Auslesen der Werte zu mehr mittlerem > Stromverbrauch und somit zu einer kleinen Eigenerwärmung führt. Dies > könnte ggf. zu Fehlern führen. > > Es ist jedoch so daß der Strombedarf im uA-Bereich liegt. Da sollte die > Eigenerwärmung klein sein und der Fehler somit dank der eingebauten > Temperaturkompensation auch. Auch eine "kleine" Eigenerwärmung spielt bei den Membranen eine große Rolle. Und wenn es sich da nur um 1°C dreht. Da gibt es hier viele Threads zu, meißt aber über die SHTxx bzw. die BMP3xx. Und ich weiß noch immer nicht wie du darauf kommst das der HDC1080 eine eingebaute Temperaturkompensation hat? Ich finde dazu nichts im Datenblatt. Kann sein, aber ich sehe dazu nichts. Das wäre ja das Merkmal in dem sich der Sensor von allen anderen abheben könnte.
Rene K. schrieb: > Und ich weiß noch immer nicht wie du darauf kommst das der HDC1080 eine > eingebaute Temperaturkompensation hat? Normalerweise sind Feuchtesensoren auch temperaturabhängig: http://www.michell.com/de/technologie/kapazitive-feuchtesensoren.htm "Sie weisen wichtige Eigenschaften wie schnelle Ansprechzeit, geringe Temperaturabhängigkeit.." Meine Vermutung ist daher daß auch der Sensor im HDC1080 eine solche Abhängigkeit aufweist. Wenn der Hersteller diese kennt so kann er das durch geeignete Kalibrationskoeffizienten ggf. ausgleichen. Leider gibt das Datenblatt nicht an welche Intelligenz hinter der eingebauten Korrektur steckt. Ich nutze dieses Datenblatt: http://www.ti.com/lit/ds/symlink/hdc1080.pdf "The HDC1080 is a digital humidity sensor with integrated temperature sensor that provides excellent measurement accuracy at very low power." "The humidity and temperature sensors are factory calibrated."
Rene K. schrieb: > Kann sein, aber ich sehe dazu nichts. Das wäre ja das > Merkmal in dem sich der Sensor von allen anderen abheben könnte. Ja. Es steht dazu leider nichts drin. Auch eine Betriebsspannungsabhängigkeit ist nicht angegeben. Ich vermute jedoch daß Schwankungen der Spannung schon einen Einfluss haben können. Dazu habe ich bisher nichts getestet.
Matthias W. schrieb: > Meine Vermutung ist daher daß auch der Sensor im HDC1080 eine solche > Abhängigkeit aufweist. Wenn der Hersteller diese kennt so kann er das > durch geeignete Kalibrationskoeffizienten ggf. ausgleichen. Leider gibt > das Datenblatt nicht an welche Intelligenz hinter der eingebauten > Korrektur steckt. Weil es da keine Intelligenz gibt, das musst du selbst machen. Du ließt Temperatur aus, rel. Feuchte und verrechnest beides. Mir ist auch kein Sensor bekannt der dies selbständig macht. Matthias W. schrieb: > Normalerweise sind Feuchtesensoren auch temperaturabhängig: Richtig, vollkommen richtig, sie sind Temperaturabhängig. Matthias W. schrieb: > "The HDC1080 is a digital humidity sensor with integrated temperature > sensor that provides excellent measurement accuracy at very low power." > > "The humidity and temperature sensors are factory calibrated." Erster Satz sagt das er einen integrierten Temperatursensor hat. In Verbindung mit dem Hum Sensor erziehlt er seine Präzision. ABER du musst dies selbst machen. Wie bei allen anderen Hum Sensoren auch. Der zweite Satz gibt halt nur an, das die Sensoren kalibriert sind, das sie bei 25°C PCB Temperatur halt auch 25°C PCB Temperatur ausgeben - und nicht 18°C z.b. - Diese Kalibrationswerte stehen halt im OTP.
Rene K. schrieb: > Weil es da keine Intelligenz gibt ich hatte schon öfter von Sensoren gelesen die einen uP verbaut haben der eine gewisse Intelligenz hat über das Programm. Wenn man das typische Verhalten bei Temperaturabweichung kennt kann man das ausgleichen. Es gibt ja auch Quarzoszillatoren wo man die Frequenz über die Temperatur geeignet stabilisiert. > Du ließt Temperatur aus, rel. Feuchte und verrechnest beides. das kann man machen wenn man den Zusammenhang kennt. Im Datenblatt steht dazu nichts. Also wird es schwer das umzusetzen. Man müsste selbst die nötigen Daten generieren.
Rene K. schrieb: > ABER du musst dies selbst machen. das werden wohl nur wenige machen wegen des Aufwands zur Datenerhebung. Dazu braucht es wohl eine Klimakammer mit einstellbarer Feuchte, Temperatur und viel Zeit. Oder kennst Du da einen raschen Weg?
Matthias W. schrieb: > das werden wohl nur wenige machen wegen des Aufwands zur Datenerhebung. > Dazu braucht es wohl eine Klimakammer mit einstellbarer Feuchte, > Temperatur und viel Zeit. Oder kennst Du da einen raschen Weg? Nein, du verwechselst da was... DIESE Werte sind bereits kalibriert in deinem HDC. Ließ dir mal folgendes durch bitte, das erklärt dir was die rel. Luftfeuchtigkeit mit der Temperatur zu tun. Auch einige Berechnungsgrundlagen: http://www.simulations-plattform.de/Thermodynamik/Relative_Luftfeuchtigkeit
Matthias W. schrieb: > Rene K. schrieb: >> Lass ihn mal 100ms. Jeweils 100ms Pause nach Starten der Wandlung habe ich nun auch probiert. Das Ergebnis ist genau dasselbe wie mit 7ms. Die bei meinem Exemplar erreichbare Auflösung ist nicht 14bit wie angegeben und auch nicht 11bit - sondern 10bit.
Rene K. schrieb: > Ließ dir mal folgendes durch bitte Vielen Dank Rene. Sieht aus wie das Thema Taupunkt. Mir ist nur nicht klar was das mit der internen Kalibrierung dieser Sensoren zu tun hat. Der Sensor gibt doch Feuchte in 0-100% aus. Ist das nicht die relative Feuchte? Ist 100% nicht die Kurve rechts in dieser Grafik? Vielleicht findet sich noch eine bessere Seite zur Erklärung des Themas. Für den Taupunkt braucht es normalerweise Feuchte und Temperatur. Daraus kann man das berechnen. https://www.wetterochs.de/wetter/feuchte.html "Aus Temperatur und relativer Luftfeuchte bzw. Temperatur und Taupunkt lässt sich auch der absolute Feuchtegehalt der Luft in Gramm Wasserdampf pro Kubikmeter ausrechnen."
Allzu viel Genauigkeit würde ich von dem HDC1080 sowieso nicht erwarten. Angeblich 14 Bit bei einer "Einheitsstromversorgung" plus der üblichen Sparsamkeit vom Chinamann. Das kannst Du vergessen. Vielleicht hilft es, wenn Du das Teil Versorgungsspannungsmäßig ordentlich entkoppelst. Aber Gipfel wirst Du damit auch nicht Stürmen können. Meine Meinung zu Deinen Abfragezyklen behalte ich lieber für mich. Erinnert mich ein wenig an die Typen, die einem schweren Stahlblock im Millisekundenrhythmus abfragen, um dessen Temperatur zu überwachen.
Ich würde auch erwarten, dass der Sensor intern kompensiert. In disen Dokus http://www.ti.com/tool/hdc1080evm steht auch nichts dazu. Versuch doch mal die Temperatur parallel zur Luftfeuchte zu loggen und schau ob es auch dort Sprünge gibt. Und prüfe die Stabilität der Betriebsspannung mit dem Oszi. Wenn alles nichts hilft leg einen Software Filter drüber.
Thomas schrieb: > Versuch doch mal die Temperatur parallel zur Luftfeuchte zu loggen Danke Thomas. Die Temperatur habe ich parallel angesehen. Die springt auch mit 10bit Auflösung hin und her. Mehr als 10bit kann ich momentan nicht sehen. Mag sein daß da Störungen auf der Versorgung sind. Mit dem Oszi das am Netz hängt sind meistens Störungen zu sehen. Auch das Laptop-Netzteil erzeugt solche. Ich kann natürlich mal den Laptop nur mit Akku laufen lassen und schauen was dann passiert.
Sebastian S. schrieb: > Vielleicht hilft es, wenn Du das Teil Versorgungsspannungsmäßig > ordentlich entkoppelst. Danke für den Hinweis Sebastian. Das Modul kann ich an einen 3.3V-Regler legen. Die I2C-Bus-Pins sollten dann jedoch an den 4.5V des uC liegen. Sonst brauche ich noch einen Pegelwandler. Das Schöne beim HDC1080 ist daß er auch 5V noch kann.
leider bekam ich von TI keinen Hinweis warum die Auflösung scheinbar so gering ist. Das Modul stammt ja aus China. Manchmal liest man von Fake-chips. Keine Ahnung ob so etwas hier der Fall ist. Es ist halt seltsam wenn die Werte so gar nicht nach 14 bit Auflösung aussehen. Insbesondere wenn man in sehr rascher Folge neue Werte bestimmt sollte sich in der sehr kurzen Zeit der Wert für Feuchte und auch Temperatur kaum ändern. Daher sollte man sehen wie die unteren bits sich dann bewegen. Eben dies war bisher bei meinem Aufbau nicht zu sehen. Eine weitere Möglichkeit ist eine eigene Platine zu machen, einen Sensor von TI nebst Spannungsregler und Level Translator vorzusehen und damit Messungen zu machen.
Angehängte Dateien:
Matthias W. schrieb: > Die Sprünge liegen bei ~0.1% Feuchte. Matthias W. schrieb: > Versorgt wird er über Arduino-nano3 per USB. Sorry aber was erwartest Du denn? Keine Saubere Versorgung ergibt nun mal hohes Rauschen. Außerdem: In bestimmten Betriebspunkten ergibt eine Temperaturänderung von 1 Grad eine Feuchtigkeitsänderung von 6%. Da reicht ein kleiner Luftzug und schon hast Du ein halbes Grad Temperaturdifferenz. Anbei mal eine Aufzeichnung von 3 Temperatursensoren (von diversen Feuchte und Drucksensoren). Man sieht deutlich eine Beruhigung der Werte wenn die Sensoren innerhalb einer Schachtel liegen. Gruß Anja
Anja schrieb: > Man sieht deutlich eine Beruhigung der Werte > wenn die Sensoren innerhalb einer Schachtel liegen. Danke Anja. Der mittlere Bereich war die Schachtel? In diesem Bereich scheint das recht glatt zu sein. Auch die Zwischenwerte scheinen vorzukommen. Da sind doch im Gegensatz zu meinen Werten mehr als 10bit Auflösung zu sehen.
Anja schrieb: > Keine Saubere Versorgung ergibt nun mal hohes Rauschen. der empfohlene Cap ist dran. Im Datenblatt fand ich keine Angaben wie stabil die Versorgung sein soll. Eine Abhängigkeit von der Versorgung ist nicht angegeben. Wenn ich die neue Platine habe kann ich mehr dazu sagen wie die Dinge dann aussehen. Ich kann natürlich auf dem China-Modul auch einen Tantal anlöten.
Anja schrieb: > Sorry aber was erwartest Du denn? > Keine Saubere Versorgung ergibt nun mal hohes Rauschen. meine Erwartung ist falls es rauscht dann auch alle Zwischenwerte mal zu sehen. Statistisch sollte jeder Wert mal auftauchen und nicht nur recht stabile Werte und dann Sprünge zum nächsten 10bit-Wert.
Anja (Gast) schrieb: >Außerdem: In bestimmten Betriebspunkten ergibt eine Temperaturänderung >von 1 Grad eine Feuchtigkeitsänderung von 6%. Wo steht das im DB des HDC1080? @TO: Grundsätzlich würde ich davon ausgehen, daß dieser Sensor bereits temperaturstabilisiert ist, wenn das DB keine sonstigen diesbezüglichen Daten hergibt. Mit der angesprochenen Hysterese hat das sicherlich auch nix zu tun, denn die würde eher zu einer Beruhigung als einer Zappeligkleit führen. Grundsätzlich solltest Du die Betriebsspannung (zumindest die, die der Sensor sieht) schön säubern, sonst wird das bei dieser Auflösung nix.
Jens G. schrieb: > Grundsätzlich solltest Du die Betriebsspannung (zumindest die, die der > Sensor sieht) schön säubern Danke Jens ! ohne einen extra Spannungsregler ist das wohl nicht so einfach. Die Idee war anfangs den HDC1080 zu nehmen weil dieser auch 5V noch kann und damit ein Betrieb direkt am uC denkbar erscheint. Natürlich wird die Spannung die aus dem USB kommt wohl nicht sonderlich sauber sein. Denkbar wäre es eine Spule in der Versorgungsleitung zur Platine vorzusehen und einen größeren C auf der Platine. Oder man verlässt diese Spannungsebene. Dann sind eben mehr Teile nötig. Scheinbar bietet kaum jemand Sensoren für Arduino mit extra Spannungsregler 3.3V und Levelshifter an.
>Denkbar wäre es eine Spule in der Versorgungsleitung zur Platine >vorzusehen und einen größeren C auf der Platine. Ja, oder Widerstand statt Spule, z.B. 100Ohm/100µ. Wird zwar leichten Spannungsabfall (paar 10mV) über den R bewirken, aber die sollten hoffentlich nicht zu sehr auf das Ergebnis einwirken, zumindest nicht in hochfrequenter Form. Jedenfalls sollten hochfrequentere Spikes damit weitgehends weg sein.
Angehängte Dateien:
Jens G. schrieb: > Wo steht das im DB des HDC1080? Das kann man aus Wikipedia herauslesen wenn man das Nomogramm für die Relation zwischen absoluter Feuchte, Temperatur und relativer Feuchte betrachtet. Das ist keine Sensor-Eigenschaft sondern Physik. Matthias W. schrieb: > Da sind doch im Gegensatz zu meinen Werten mehr als 10bit > Auflösung zu sehen. Ist die Auflösung die des ADCs oder die des ausgegebenen Feuchte-Wertes? Und auch ganz sicher daß beim shiften nichts verloren geht? Auf der anderen Seite: mehr als 1% Auflösung bei Feuchte ist eh gelogen. Matthias W. schrieb: > der empfohlene Cap ist dran. Besser wäre ein RC oder LC-Filter. so 10-47 Ohm je nach Strombedarf des Sensors und einen dicken Elko zusätzlich zu den 100 nF. Matthias W. schrieb: > Danke Anja. Der mittlere Bereich war die Schachtel? In diesem Bereich > scheint das recht glatt zu sein. Genau: Die Werte sind alles Temperaturen. Man sieht auch schön daß die Selbsterwärmung unterschiedlich ist. Außer wenn der Lüfter an ist (im Diagramm die beiden Einbrüche am Anfang der Aufzeichnung bei 4000 und 8000 Sekunden). Anbei noch die Feuchte von der Aufzeichnung. (SHT21 als Sensor). Auch hier deutlich ruhigere Werte im mittleren Bereich außer beim Auspacken. Gruß Anja
Anja schrieb: > Und auch ganz sicher daß beim shiften nichts verloren geht? so ein Hexenwerk ist das Shiften nicht. So ganz falsch kann es nicht sein denn es kommen ja plausible Werte an. Ich hatte auch noch eine Fassung gemacht wo gar nicht nach rechts geschiftet wurde und die Werte dann eben größer sind. Momentan überlege ich das neu aufzubauen mit 3.3V-Regler und Original-Chip statt China-Billig-Fertig-Platine.
Anja schrieb: > so 10-47 Ohm je nach Strombedarf des Sensors und einen dicken Elko > zusätzlich zu den 100 nF. das kann ich noch machen. Der Sensor braucht sehr wenig Strom. Viel mehr Strom brauchen die I2C-Widerstände auf der Platine. Die kann ich jedoch deaktivieren.
Anja schrieb: > Ist die Auflösung die des ADCs oder die des ausgegebenen Feuchte-Wertes? für mich sah es so aus als ob der chip nicht mehr Auflösung als 10bit liefert. So als ob der ADC auf dem chip nicht mehr kann. Nur was macht so ein Redesign des chips für einen Sinn? Wenn nur ein 10bit-Wandler da wäre würde das erklären warum keine Werte durch Rauschen dazwischen auftauchen.
Anja schrieb: > Anbei noch die Feuchte von der Aufzeichnung. (SHT21 als Sensor). > Auch hier deutlich ruhigere Werte im mittleren Bereich außer beim Auspacken Danke Anja. Kannst Du die Auflösung im mittleren Bereich mal größer zoomen damit ich sehen kann wie groß die Sprünge da sind? Ich nehme an daß Du mit 12bit da gearbeitet hast? Der SHT kann laut Datenblatt keine 14bit.
Moin, für mich bedeutet - 14 Bit Measurement Resolution, dass der Sensor mit 14Bit eingelesen wird (ADC). Das hat erst einmal nichts mit der Auflösung oder dem Rauschen der Ausgabe zu tun. Weiterhin steht dort: - Repeatability bei 14Bit Messauflösung: 0,1%RH. Heißt für mich, dass alles besser als 0.1%RH keine Aussagefähigkeit hat. Egal wie viele Bits im Ausgangsregister oder im Ausgabewert stehen, Änderungen kleiner 0.1%RH sind Rauschen, Messfehler oder Conversionfehler. Wenn zwei Messwerte mit 14Bit eingelesen werden (Feuchte und Temperatur) und daraus ein relativer Feuchtewert ermittelt wird, sind meiner Meinung keine 14Bit echte/rauschfreie Auflösung im Ausgang möglich. Man muss die Marketinginformation vom technisch Relevanten trennen :-) ... mein kleiner Beitrag...
@TO: Der HDC1080 ist von der Genauigkeit deutlich besser als der Si7020. Man muss sich aber vor Augen führen, dass selbst kommerziell erhältliche (und sauteure) Salztöpfe zur Kalibrierung nur +/-3% erreichen, siehe https://shop.bb-sensors.com/out/media/Datenblatt_Feuchte-Referenzzellen.pdf. Die 2% des HDC1080 sind also schon sehr gut. 14 Bit Genauigkeit (das wären rund 60ppm) sind utopisch. Ganz abgesehen davon, dass die Feuchte in einem beliebigen Raum wohl kaum so homogen verteilt sein dürfte, dass die Aussage irgendeinen Nutzen hätte. Ein genauerer Abgleich als mit der Referenzzelle dürfte nur mittelbar über die Taupunktbestimmung möglich sein. Dass man dabei die Temperatur extrem genau kontrollieren muss, ist trivial. Auch bei der Variante mit der gesättigten Salzlösung ist es wichtig, die Temperatur konstant zu halten. Ohne Styroporbox oder besser noch Klimaschrank kommt da nur Mist raus. Die Wetterochs-Seite wurde ja schon genannt, spiele mal ein bisschen mit den Werten, was sich da schon bei 0,1K Temperaturunterschied tut. Sobald dein Gerät sich irgendwie selbst erwärmt (und da reicht schon ein µC oder eine LED in der Umgebung), ist dein Feuchtewert schon Unfug und du musst umrechnen. Die Formeln vom Wetterochs liefern prima Ergebnisse. Für 60ppm dürften seine Konstanten aber nicht reichen. @Anja, schön, mal wieder von dir zu lesen - gefühlt ist das letzte Mal eine Ewigkeit her. Ich mag mich aber täuschen.
Viele Bits und wenig Inhalt schrieb: > Änderungen kleiner 0.1%RH sind Rauschen, Messfehler oder > Conversionfehler. Danke für den Beitrag ! wozu bietet man 14bit an wenn ich am Ende nur 10bit sehe? Klar sind Messfehler da. Natürlich sind die auch viel größer als die Auflösung. Nur welchen Sinn macht es 14bit zu realisieren wenn ich beim Auslesen schlicht keiner dieser 4 bits über 10 bit hinaus dann sehen kann? Ein reiner Marketing-Gag? mehr nicht? Meine Hoffnung und Erwartung war daß die erhöhte Auflösung im 14bit mode zumindest erlaubt einen Trend frühzeitig zu erkennen. Was sonst hat man dann davon?
Max G. schrieb: > Die Formeln vom Wetterochs liefern prima Ergebnisse. Vielen Dank Max. Leider sind die Formeln nicht so einfach im Controller nutzbar. 10^ ist da dabei, log10 und float-Arithmetik. Man könnte natürlich auch Tabellen nutzen und interpolieren.
Max G. schrieb: > Sobald dein Gerät sich irgendwie selbst erwärmt man kann Erwärmung des Sensors auch simulieren indem man den Heater aktiviert. Die Werte verändern sich dann. Die Feuchtewerte scheinen dann wenig Lust zu haben danach wieder auf die alten Werte zu gehen. So schien es mir. Das Vergleichshygrometer zeigte dann einen größeren Unterschied an.
Hallo, den allgemeinen Zusammenhang gibt auch als Diagramm: (Leider nur noch hier zu finden:) http://www.calorex.ro/tehnic/PsychrometricChart-SI.PDF Wobei ich persönlich den Taupunkt für besser halte. Der ist unabhängig von der Sensor-Temperatur (Selbst-Aufheizung). Oftmals heizen auch die Pull-up Widerstände vom I2C ganz schön. (Die sollten nicht zu dicht am Sensor sitzen). Gruß Anja
Anja schrieb: > den allgemeinen Zusammenhang gibt auch als Diagramm: > http://www.calorex.ro/tehnic/PsychrometricChart-SI.PDF vielen Dank Anja. > Oftmals heizen auch die Pull-up Widerstände vom I2C ganz schön. > (Die sollten nicht zu dicht am Sensor sitzen). da hast Du sicher recht. Auf meiner neuen Platine sind die nun leider etwas näher dran weil ich das Design wegen dem Abblock-C am Level-Shifter noch mal verändert habe. Dafür sind die Widerstände ja dann nur an 3.3V.
Matthias W. schrieb: > Vielen Dank Max. Leider sind die Formeln nicht so einfach im Controller > nutzbar. 10^ ist da dabei, log10 und float-Arithmetik. Man könnte > natürlich auch Tabellen nutzen und interpolieren. Das geht auch in fixed-point, mit einer Taylorreihenentwicklung bis zum dritten Glied kommt man da sehr weit. BTDT. Leider habe ich keinen Weg gefunden, die Division zu umgehen :(
Matthias W. schrieb: > Die Feuchtewerte scheinen dann > wenig Lust zu haben danach wieder auf die alten Werte zu gehen. Das nennt sich Hysterese. (Fußnote 8 zur Tabelle im Abschnitt 7.5 vom Datenblattes des HDC1080)
Max G. schrieb: > mit einer Taylorreihenentwicklung bis zum > dritten Glied kommt man da sehr weit. Danke Max ! Du meinst das ist der bessere Weg im Vergleich zu einer Tabelle?
Wolfgang schrieb: > Das nennt sich Hysterese. Danke Wolfgang. Das schien mir bei meinem Versuch unerwartet groß zu sein.
Angehängte Dateien:
-
data.png
8,7 KB
um der scheinbar zu kleinen Auflösung (weniger als 14bit bei Einstellung 14bit) weiter auf den Grund zu gehen habe ich bei Mouser das Original TI HDC1080EVM erworben und die Original-Software installiert. Leider zeigt auch dieses Modul die schon bekannten unerwartet großen Sprünge. Siehe das Bild. Die rote Kurve ist die Luftfeuchte und die grüne die Temperatur. Die Werte sehen recht trocken aus. Das EVM-Modul war links am Laptop angesteckt in der Nähe des Auslass des CPU-Lüfters. Mag sein daß die Luft daher so trocken war. Als ich die Hand dem Sensor näherte stieg die Feuchte (rot) an und mit Verzögerung auch die Temperatur (grün). Man sieht daß die Quantisierung der Feuchte in etwa bei 0.1° liegt. Das entspricht der Größenordnung die ich mit dem billigen China-Modul herausgemessen hatte. An diesen Modulen scheint es also nicht zu liegen wenn keine 14bit zu sehen sind. Mit dem Original TI-Modul sieht man 14bit auch nicht. Dabei kann man mit dem EVA-Modul von TI die Auflösung 14bit am GUI vorwählen und die Daten in ein csv schreiben lassen. Die Grafik zeigt den Verlauf der Daten bei Abfrage alle Sekunde. Mittlerweile habe ich eine Platine für den Chip nebst Spannungsregler und Pegelwandler angefertigt. Nur bestückt ist diese noch nicht. Es ist zu erwarten daß die Daten auch damit so springen werden wie beim EVA-Board und bei den China-Modulen. Das Problem liegt wohl im Design des Chips begründet. So klingt es doch. TI hatte bisher keine plausible Erklärung.
hier weitere Messungen mit dem Original TI EvaBoard HDC1080. Dabei wurde der USB-Stick hinten am Laptop angesteckt. Der Lüfter spielt so keine große Rolle mehr. Oben Feuchte, unten Temperatur. Parallel dazu wurden in unmittelbarer Nähe Werte mit 2 China-Modulen mit HDC1080 ermittelt und mit einem Feuchtemesser von Barigo. Die Sensoren zeigen stark unterschiedliche Werte: - Sensor auf Eva-Board zeigt stets um die 30% Feuchte - Sensor in China-Modul 1 zeigt ~47.5% - Sensor in China-Modul 2 zeigt ~45.5% - Sensor im Barigo zeigt ~50% Es ist auffallend daß die beiden China-Module noch am ehesten zum Barigo passen und daß das Eva-Board von TI davon stark abweicht. So große Abweichungen sollten eigentlich nicht auftreten. Fazit: Die sichtbare Auflösung des HDC1080-Sensors entspricht bei der Feuchte nicht 14bit. Bei der Temperaturmessung ist eine deutlich bessere Auflösung zu sehen obwohl das dieselbe Auflösung sein sollte laut Einstellung im Modul. Die Feuchtewerte des TI-Moduls mit HDC1080 erscheinen unplausibel zu klein. Ob als Ursache ein Sensorfehler, Softwarefehler oder Firmwarefehler in Frage kommt wäre zu klären.
Rühre dir mal eine gesättigte Kochsalzlösung an und packe den Sensor mit der Lösung in ein Behältnis. Über gesättigtem NaCl stellt sich eine rF von 75,5% ein, dann kannst du recht gut sehen, was Sache ist. Der HDC1080 ist nach meinen Erfahrungen aber entweder sehr genau oder (bei wenigen Exemplaren) total daneben. Zu niedrige rF ist gerne mal auch einer Eigenerwärmung geschuldet...haben die Sensoren die gleiche Temperatur?
Max G. schrieb: > Rühre dir mal eine gesättigte Kochsalzlösung an vielen Dank Max für den Hinweis. > Der HDC1080 ist nach meinen Erfahrungen aber entweder sehr genau oder > (bei wenigen Exemplaren) total daneben. es sieht so aus als ob ggf. der Sensor auf dem TI-Board defekt ist (Feuchte total daneben). Das Teil kam über Mouser und war sehr gut verpackt (Karton, Plastiktüte, Karton, Schaumstoff, leitfähige Tüte verschweißt mit Silicagelbeutel innen, noch mal extra Tüte). Mehr Verpackungsaufwand ist kaum möglich. Mit der gleichen Sendung kamen noch 2 HDC1080-Sensoren. Die sind noch originalverpackt. > Zu niedrige rF ist gerne mal > auch einer Eigenerwärmung geschuldet...haben die Sensoren die gleiche > Temperatur? die Temperaturen sehen ähnlich aus (siehe die grünen Linien unten in den Grafiken). Alles um die 25°C Raumtemperatur direkt hinter dem Laptop.
Angehängte Dateien:
-
data2_zoom_temp.png
7,3 KB -
data2_zoom_humidity.png
6,3 KB
hier ein Zoom aus den Daten des Original-TI-Eva-Boards. Man sieht daß - obwohl 14bit-Auflösung für Feuchte und Temperatur gewählt wurde die Feuchte deutlich gröber als die Temperatur quantisiert ist. Wenn das bei der Temperatur 14bit sind dann sind es keine 14bit bei der Feuchte. Das sind Daten die TI mittels des Moduls selbst so liefert. Da spielen also keine etwaigen Softwarefehler von mir eine Rolle.
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.