Bascom Sensor HYT221 - Umrechnung der Rohdaten

[Uwe H.]

Gruesst euch

Auf Dinos Empfehlung irgendwann mal vor ein paar Monaten hab ich mir fuer ne Wetterstation einen HYT221 Feuchte/Temp-Sensor geleistet. Das Ding funktioniert auch einwandfrei unter I2C, nur stimmen die Messwerte fuer die Temperatur bei mir nicht wirklich (125 Grad Raumtemperatur). Die Feuchtigkeit klingt plausibel (um die 60%). Als Referenz tuckert bei mir nebenher ein DHT22. Das Datenblatt ist leider keine grosse Hilfe oder ich bin zu bloede es zu interpretieren. Leider konnte ich es hier nicht anhaengen, ist 130kb zu gross


Ich lese die Sensordaten vom HYT momentan per Logic16 aus und rechne per Hand nach. Die uebertragenen Bytes gliedern sich aus:

MSB(Hum) - LSB(Hum) - MSB(Temp) - LSB(Temp)

und die Messwerte sehen folgendermassen aus:

38 - 206 - 94 - 92


Mein Rechenweg fuer Humidity:

Formel im Datenblatt fuer Humidity: rH [%] = 100 / 2^14 * rHraw

(38*256)+206 = 9934 'Wert der Word-Variable fuer den Feuchtigkeitswert
2^14 = 16384
100/16384 = 0,006103515625
9934*0,006103515625 = 66,6323......
Sprich 60,63% Feuchtigkeit

Jetzt die Temperatur:

Formel im Datenblatt fuer Temperatur: T [°C] = 165 / 2^14 * Traw - 40

(94*256)+92 = 24156 'Wert der Word-Variable fuer den Temperaturwert
2^14 = 16384
165/16384 = 0,01007080
16384*0,01007080 = 164,99
164,99-40 = 124,99 C?

Wo verd... nochmal liegt der Fehler...? Google zu quaelen hat leider nicht viel gebracht, zu dem Sensor sind wenig Infos verfuegbar. Bei mikrocontroller.net hatte jemand ein aehnliches Problem aber natuerlich hat er anschliessend keine Loesung dazu gepostet Laut dem, was ich da lesen konnte, sind die Formeln richtig. Hat hier jemand vielleicht eine Idee?

 

[for_ro]

Hallo Uwe,
laut der I2C Protocol Description des Sensors sind nur die Bits 0...13 relevant. Bei deiner 94 ist aber das Bit 14 gesetzt. Bit 14 (Stale Bit) hat danach die Bedeutung, dass noch kein neuer Wert berechnet wurde.
Wenn du das rausmaskierst bleibt noch der Wert 30 im MSB, was eine Temp von 38° entspricht. Ist das realistisch?

 

[Ditron]

Auf ein brauchbares Ergebnis komme ich momentan auch nicht.

Aber warum findet sich der Wert 24156 in deiner Rechnung nicht wieder?


Edith sagt:
Vielleicht bringen die Erkenntnisse von for_ro und mir die Lösung?

 

[Uwe H.]

Oh sorry, ich hab die Daten durcheinander gebracht weil ich den Rechenweg von Hum kopiert hab. So muss es aussehen:


Formel im Datenblatt fuer Temperatur: T [°C] = 165 / 2^14 * Traw - 40

(94*256)+92 = 24156 'Wert der Word-Variable fuer den Temperaturwert
2^14 = 16384
165/16384 = 0,01007080
24156*0,01007080 = 243,27
243,27-40 = 203,27 C

Damit ist das Ergebnis noch weiter von der Realitaet entfernt. Was for_ro sagt ist richtig, jedoch gilt dieses fuer das erste uebertragene Byte der Kette, sprich MSB(Hum). Aber natuerlich hab ich es auch bei Temp probiert und bekomme auch um die 39 Grad raus, was falsch ist. Die tatsaechliche Temperatur betrug 22,1 Grad. Laut dem HYTProtocoll.pdf sind bei der Temperatur die letzten beiden Bits des LSB wegzumaskieren. Bei dem Beispiel der Berechnungsformel sind allerdings wieder die ersten beiden des MSB wegmaskiert. Das Datenblatt widerspricht sich auf seinen drei Seiten xmal sich selbst. Ich krieg ne Krise hier mit dem Teil... Welcher Honk hat dieses Datenblatt bloss geschrieben

 

[for_ro]

Wenn die unteren 2 Bits wegmüssen, dann bedeutet das doch, dass der eingelesene Wert 24156 durch 4 geteilt werden muss.
Dann kommt etwa 21° heraus, was doch schon gut übereinstimmt.

 

[Uwe H.]

S......e, Du hast Recht.... Das Ergebnis kommt der Realitaet verdammt nah. Ich hab nochmal das Datenblatt gelesen aber kann nur mit wirklich viel Phantasie eine direkte Aufforderung zu "2x Shift right" finden. Da steht nur, dass die Bits wegmaskiert werden sollten, was auch eine simple AND-Funktion sein kann, so wie bei der Feuchtigkeit. Ich kopiere mal den ausschlaggebenden Text hierher:

DF (Data Fetch)
The data fetch command serves to finish reading
the output register. The DF command is sent by the
master to the humidity module (slave) and begins
with the 7 Bit slave address. The 8th bit is 1 (=
read). The Humidity module sends back an ac-
knowledgement (ACK =0) in case of correct ad-
dressing.
The number of bits, that the humidity module sends
back, is completed when the master sends a NACK
(ACK= 1) and launches stop condition. The first two
bytes of measurement data contain the two status
bits as MSB, followed by the humidity value with 14
bits.
If temperature data is needed, these can be read
after the humidity value. The most significant 8 bits
of the temperature value will be transferred as third
byte. Then the least significant 6 bits of the tem-
perature value can be read as the fourth byte. The
last two bits are not used and should be masked
away.
The master has the possibility to terminate the
reading after each read byte through a NACK.
Hence, it is possible to finish reading even after the
first byte and evaluate only the status/stale bit and
the master can terminate the transfer without com-
pleting the whole cycle. If only the upper 8 bits of
the temperature value are to be transferred (8 bit
resolution), the transfer can be aborted after the
third byte by a NACK.


Das Datenblatt findet sich unter:
http://www.ist-ag.com/eh/ist-ag/resource.nsf/imgref/Download_AHHYT-I2C_E1.1.pdf/$FILE/AHHYT-I2C_E1.1.pdf

 

[for_ro]

Ist doch logisch, die nennen die Bits doch auch 13....0. Wenn die sie - warum auch immer - nicht rechtsbündig übertragen, dann musst du sie rechtsbündig shiften.
Auch aus der Rechnung wird klar, dass der maximal zu erwartende Wert 2^14 -1 ist, sonst würde die Temperatur über 165 gehen, also über 125°.

 

[Uwe H.]

Ich verfrachte morgen mal beide Sensoren in den Kuehlschrank und mache dann eine Ablesung. Mal sehen, ob die Werte stimmen. In meinen Augen ist es Idiotie, im Prinzip treffen sich bei der Berechnung zwei verschiedene Methoden. Einmal das Maskieren mit AND 3FFF bei der Feuchtigkeit und das Shiften bei der Temperatur. Haette man nicht beides so oder so machen koennen? Wer denkt denn an so eine Vorgehensweise, wenn noch dazu die Formeln fast identisch sind
Fuer den Preis, den der Sensor kostet, sollte man wirklich ein vernuenftigeres Datenblatt erwarten koennen, in dem man ohne langes Kombinieren und nerviges Testen zumindest den Loesungsweg gezeigt bekommt. Bei Dallas (z.B. DS18B20) geht das doch schliesslich auch und da gibts nen Haufen Befehle mehr.

Vielen Dank schonmal fuer deine Hilfe. Ich hoffe, dass ist die Loesung.

 

[Uwe H.]

Bin grad von der Nachtschicht gekommen, Fenster war Zuhause ueber Nacht offen, gemessene Temperatur des Refferenzsensors:
68,6% Hum
19,3 Grad

Messung des HYT mit zweimal shiften nach rechts:
67,1% Hum
17,3 Grad

Das sind zwei Grad Unterschied. Hab die Messungen mehrmals durchgefuehrt. Es bleiben genau zwei Grad. Die Refferenzquelle ist ein DS18B20, der kann sich bis zu 0,5 Grad verhauen. Der HYT hat 0,2 Grad Toleranz. Sprich, die Abweichung ist mit zwei Grad etwas zu hoch :-(

 

[LotadaC]

Wenn dieses Byte mit den Bits geringster Relevanz das letzte in der Übertragung ist, kann diese Anordnung Sinn machen:
Reicht die Auflösung von 8bit aus, Dann kann der Master nach Empfang des Bytes mit den 8 höchstwertigsten Bits die Übertragung terminieren, und das empfangene Byte (ohne Schieberei) verarbeiten. Letztendlich nichts anderes, als der ADC im AVR (nur, daß der eben 10 Bits auf 2 Bytes verteilen muß).

Der DS18B20 liefert (wenn ich mich recht erinner) das Ergebnis als vorzeichenbehaftetes Word (also 2 Bytes), wobei das highest Nibble "verschenkt" ist (außerhalb des Bereiches - vom Komplement mal abgesehen)). Auflösung ist 1/16°C.

 

[Uwe H.]

Grues Dich Lothar,
die Berechnung haut nicht hin. Hab heute den Sensor mal zusammen mit einem DHT22 (Feuchte+Temp in den Kuehlschrank gepacktum zu sehen, wie die Sache sich entwickelt.
Die Feuchtigkeit wurde vom HYT mit 63% berechnet, vom DHT mit ca. 50%. Temperatur im Kuehlschrank ist 8,4 Grad, der HYT kommt auf 0 Grad. Es sieht so aus, dass bei Raumtemperatur die Abweichung gering ist, aber bei sinkender Temperatur immer mehr nach unten zunimmt. Die Gegenprobe waere jetzt hohe Temperatur. Wenn der HYT dann zuviel anzeigt und der Unterschied mit steigender Temperatur ebenfalls steigt waere klar, dass die Rechnung nicht stimmt.

 

[dino03]

Hi,

Die Feuchtigkeit wurde vom HYT mit 63% berechnet, vom DHT mit ca. 50%. Temperatur im Kuehlschrank ist 8,4 Grad, der HYT kommt auf 0 Grad. Es sieht so aus, dass bei Raumtemperatur die Abweichung gering ist, aber bei sinkender Temperatur immer mehr nach unten zunimmt.

hmmm ... sehr seltsam. Wenn ich Zeit hätte, dann würde ich das mal bei mir nachstellen. Ich hab da ja auch ein paar von rumliegen. HYT371, HYT321, HYT939. Wenn denn das leidige Zeitproblem nicht wär

Gruß
Dino

 

[Uwe H.]

Gruess Dich Dino

Die Sache ist in der Tat seltsam und wie schon so oft muss es mal wieder mich treffen :-( Am Wochenende muss ich den Fuehler beim Kunden montieren, bis dahin brauche ich den korrekten Algorythmus. Wie sieht denn dein Rechenweg aus und hast Du den Sensor mal unter verschiedenen Bedingungen abgeglichen? Nach dem Kuehlschranktest heute ist zumindest eins 100%ig sicher:
Beide Berechnungen (Hum und Temp) sind nicht korrekt.

Im Kuehlschrank ein negativer Temperaturunterschied von 8 Grad zum DHT. Die Feuchtigkeit ist noch schlimmer, bei 70% rH auf dem DHT zeigt mir der HYT schon ueber 90%. Sprich hier geht der Messfehler in die andere Richtung. Hab zur Absicherung drei DHTs in den Kuehlschrank gepackt und alle verglichen, um sicherzustellen, dass der Fehler tatsaechlich beim HYT liegt.
Eine Beschaedigung beim HYT will ich mal vorsichtig ausklammern. Wir haben letztes Jahr dasselbe Problem mit einem anderen HYT221 gehabt, bei 70% Feuchte war er bereits bei ueber 90%. Nur hab ich das Problem damals nicht weiter verfolgt. Auch habe ich ein Bascombeispiel zum HYT221 im Netz gefunden, da rechnet der Autor statt mit 2^14 mit 2^16, was aber zu dem gleichen Ergebnis wie beim Shift right, 2 fuehrt.

 

[dino03]

Hi Uwe,

Wie sieht denn dein Rechenweg aus und hast Du den Sensor mal unter verschiedenen Bedingungen abgeglichen? Nach dem Kuehlschranktest heute ist zumindest eins 100%ig sicher:
Beide Berechnungen (Hum und Temp) sind nicht korrekt.

wie gesagt ... ich hab sie hier "rumliegen" Ich hab leider noch nix damit gemacht weil ich noch keine Zeit dafür hatte. Ich hab hier auch noch Beschleunigungs und Kompassensoren rumliegen. Magnetfeldsensoren und Drucksensoren auch. Also eigentlich alles da um ne schöne Wetterstation zu bauen. Nur es fehlt die Zeit. Die Daten von den Teilen waren für mich eigentlich absolut überzeugend. Irgendwo muß da noch ein Wurm drinstecken. Das die so danebenliegen kann ich kaum glauben. Für den Preis sollten die schon im Toleranzbereich von maximal +/-1°C liegen (wenn nicht besser). Im deutschen 2seitigen Datenblatt steht ja auch im Kopf ...

• Messbereich 0 … 100 % rF, -40 … 125 °C
• Genauigkeit ±1,8% rF, Temperatur ±0,2 °C
• Spritzwassergeschützt mit Schutzfilter
• wasserdichter Membranfilter
• präzise kalibriert und temperaturkompensiert
• chemisch beständig, betauungsresistent
• mechanisch robust
• geringe Hysterese, kompensierter Lineari-tätsfehler und Temperaturdrift
• SIL-Anschlüsse, steckbar, RM 1,27mm
• I2C, Adresse 0x28 oder Alternativadresse
• Abmessungen 15,3 x 10,2 x 5,3 mm
• RoHS konform

Darum kann ich nicht verstehen warum die bei dir so daneben liegen

Gruß
Dino

 

[Uwe H.]

Der Fuehler liegt sicher nicht daneben, der Algorythmus ist nur falsch. Such mal im Internet nach einer Protokollbeschreibung fuer die Kommunikation und Berechnung. Du findest nur eine Einzige und die ist derart widerspruechlich und behindert geschrieben, dass Du am Ende garnicht mehr weisst, was eigentlich Sache ist. Kuck mal auf Seite 1 dieses Beitrags, da ist ein Link zu dem Protokoll. Zieh es Dir mal rein und rechne anhand der Rohdaten, die ich auf Seite 1 angebe, selbst nach. Die Formel passt hinten und vorne nicht. Es ist bei verschiedenen Temperaturen eindeutig eine Verschiebung zu erkennen.

Schmeiss doch mal einen von deinen Fuehlern an und probier es. Der Code ist mehr als simpel. Schliess deinen Logicanalysator an I2C und rechne die Rohdaten mal anhand der Formel nach. Hier das Programm zum auslesen:

Do
I2Cstart
I2Cwbyte &H50
I2Cstop

waitms 600

I2Cstart
I2Cwbyte &H51
I2Crbyte Hum_msb
I2Crbyte Hum_lsb
I2Crbyte Temp_msb
I2Crbyte Temp_lsb
I2Cstop

wait 2

loop
end

Mehr hab ich bei mir auch nicht am laufen. Ich lese direkt vom Analysator ab und rechne mit dem Taschenrechner

 

[dino03]

Ich hab mal nach einigen Infos gesucht ...

bascom-forum.de - Bascom Beispiel für HYT 271 (I2C Feuchtesensoren) (mit Beispiel)

mikrocontroller.net - Hygrosens HYT221 an Atmega8 macht nichts
(vielversprechend)

I2C Adresse beim HYT271 Feuchtesensor einstellen

google.de : ZSSC3122-datasheet.pdf

www.mikrocontroller.net - Hygrosens HYT271 I²C-Adresse / Comm_lock bits ändern

das sind die vielversprechendsten Infos zu dem Sensor. Einiges ist zwar in C, läßt sich aber soweit recht gut in Bascom konvertieren.

EDIT: Beim ersten Bascom-Link ...

Vielleicht sind sie doch zu ungenau.

Ich hatte z.B. 3 Sensoren nebeneinander liegen und sie wichen im höheren Bereich je 6% Luftfeuchte voneinander ab (z.B. 64% - 71% -77%). Das ist eine ganze Menge - trotz der angegebenen Mess(un)genauigkeit von 3% (Datenblatt).

Das hört sich ja nicht so doll an. Für "ungenau" sind mir die eigentlich etwas teuer Wenn das tatsächlich stimmt und man sich nichtmal auf nen Datenblatt verlassen kann dann wäre das doch schon recht ätzend. Es gibt die zwar mit verschiedenen Genauigkeitsklassen aber die sollten doch wenigstens in ihren Spezifikationen liegen.

Den KFS140 hab ich hier auch noch liegen. Das ist aber ein kapazitiver Sensor der noch einen Meßoszillator benötigt und danach das ganze Gedöns noch kallibriert werden muß. Den hab ich mir besorgt bevor es bei Reichelt die I2C-Sensoren gab. Die I2C-Sensoren hab ich hier auch schon ne ganze Zeit rumliegen.

Gruß
Dino

 

[Uwe H.]

Die Artikel kenne ich schon. Bei Mikrocontroller.net sind leider mehr Theoretiker wie Praktiker, da wird ueber Wochen philosophiert und sich im Kreis gedreht. Ein Kompetenzbeispiel, bei dem mir vor Lachen fast die Zahnfuellungen geplatzt sind:
...............................................................................................
Autor: Voggi (Gast)
Datum: 24.02.2013 16:28

hab mir die HYT_I2C_Beispiele.zip geladen Beispiel funktioniert gut mit
Arduino (hab das Teil jetzt 36 Std ), nur leider verändern sich die
Werte nicht.
................................................................................................

Funktioniert super, tatsaechlich

Ok, zurueck zum Thema. Summa summarum haben vielleicht zwei Leute den Sensor dort tatsaechlich real getestet und das Ergebnis ist dasselbe:

1. Bei Raumtemperatur ist das Ergebnis mehr oder weniger plausibel
2. Bei fallender Temperatur verschiebt sich der Messwert TEMP nach unten (HYT = 20, REF = 22 / HYT = 0,2, REF = 8,8)
3. Bei steigender Feuchtigkeit verschiebt sich der Messwert HUM extrem steil nach oben (HYT = 92%, REF = 70,4%)
4. Mit dem Datenblatt kann man sich im Prinzip den A...h abwischen, es fehlt die Haelfte an Infos, es ist widerspruechlich in vielen Punkten, der Algorythmus passt, so wie er dargestellt wird, nicht.


Nach wiederholtem Lesen des Beitrags im m.net bin ich genauso schlau wie vorher, weil anscheinend keiner bis auf einen das Teil bei niedrigen Temperaturen getestet hat. Ihm ist zwar aufgefallen, dass die Temp nicht stimmt, hatte aber keine Referenz fuer Feuchtigkeit. Und seine Fragen diesbezueglich gehen in dem ueblichen Tumult groesstenteils unter. Anschliessend wiederholt sich die Diskussion um die Adresse des Sensors noch xmal, weil es so schwer ist an &H28 noch ein Bit dranzukleben und damit auf &H50 zu kommen Letztendlich wird der bereits bekannte Algorythmus mit einer kleinen Korrektur fuer gut befunden, aber tatsaechlich nur von den Leuten, die den Sensor wohl ausschliesslich auf dem Schreibtisch testen. Die anschliessende "Zusammenfassende entgueltige Anleitung fuer den HYT221" von einem der User dort gibt das selbe wieder, was sich hier bereits als fehlerhaft erwiesen hat. Lediglich einer hat sich die Muehe gemacht und versucht, eine Gleichung aufzustellen, die die Werte den tatsaechlichen Bedingungen naeherbringen.
Ich versuch morgen mal jemanden bei Hygrosens telefonisch zu erreichen und werd nachfragen, ob man fuer ein korrektes Datenblatt mit korrektem Algorythmus extra bezahlen muss. Auf Emails antworten die Jungs da bekanntlich nicht so gern.

Fuer den Preis, was der Sensor kostet, sollte man wirklich ein vernuenftiges Datenblatt erwarten koennen.

 

[LotadaC]

Nach Dinos Auszug aus den Features (#14) sind die Daten bereits präzise, Temperatur- und Linearitäskompensiert.
Hast Du Dir diesbezüglich mal die Raw-Daten angesehen (also bei der Feuchte ohne die beiden MSB, und bei der Temp rechtsorientiert)? Laut Features sollten die linear sein - ist das nicht der Fall, dann stimmt logischerweise die lineare Auswertung/Umrechnung auch nicht.
Sind die Rawdaten linear, ist zu untersuchen, wo die Abweichung "erzeugt" wird. Ich spekuliere jetzt mal (Bascom + Beitrag #4), daß Du Fließkommavariablen verwendest... mit welcher Genauigkeit?
(Fließkomma ist eigentlich nix für die AVR...)

Also, schau Dir erstmal die Rawdaten in den extremeren Bereichen an...

 

[biker]

Hi Uwe,

unter folgendem Link kannst du ein Bascom Beispielprogramm herunterladen welches für den HYT271 geschrieben ist
(Lesen der Werte und berechnen der Werte).

http://www.hygrochip.com/fileadmin/...te/Digitale_Feuchtesensoren/BascomHytRev2.bas

Es funktioniert aber auch mit dem HYT221.
Ich betreibe damit den HYT221 Sensor. Die Temperaturwerte vom HYT221 habe ich mit dem DS18S20 bei Raumtemperatur überprüft,
die Werte stimmen. Die Feuchtigkeitswerte habe ich mangels Vergleich nicht überprüfen können, sie sehen aber meiner Meinung
nach richtig aus.
Anbei auch noch eine I2C Protokollbeschreibung. Ich denke damit müsstest du dem Sensor die richtigen Werte entlocken können.

Gruß
Biker

 

[LotadaC]

Ist das mit der Zuweiserei der Antworten nicht unnötig umständlich?
Die Rawdaten werden je in 2 Bytes im Speicher abgelegt. Dann wird das Highbyte Maskiert (Feuchte), und in das Antwort-Word geschrieben (als low-byte). Dann wird es an die Position des highbyte geschoben (Bitweise! das sind 8 Shifts bzw RORs). anschließend wird das original-lowbyte draufaddiert... Bei der Temp ists ähnlich.

Warum das Antwort-word nicht als Overlay über die Rawdaten, und diese direkt manipulieren? Dann wäre man hier nach dem maskieren bereits fertig, bei der Temp müßte lediglich das 2malige rechtsschieben (also 4 Schifts/RORs).
Aber so ähnlich wird der TE sicher gerechnet haben...