FOST02 - Feuchtigkeit immer bei 0.1

[Robert K. (r0bert)]

Hallo,
ich beschäftige mich seit kurzer Zeit mit Mikrocontrollern und versuche 
gerade einen FOST02 Temperatur/Feuchtigkeitssensor an einem Atmega8 
(1MHz interner Takt) zu betreiben. Das ganze wird in C programmiert und 
ich benutze die Library libsht_0v3 die man hier im Forum finden kann.
Das Ergebnis wird auf einem LCD ausgegeben, die Temperatur wird auch 
korrekt angezeigt, nur die Feuchtigkeit steht immer auf 0.1.
In der Library habe ich diese Zeile gefunden:

if(rh_true<0.1)rh_true=0.1;

und genau diese setzt das Ergebnis stetig auf 0.1 der gemessene Wert ist 
also immer unterhalb dieser Marke.
Ich habe mehrere FOST02, einen mit angelöteten Beinchen um ihn in einem 
Steckbrett zu betreiben, aber auch die anderen wo noch nicht gelötet 
wurde zeigen das gleiche Verhalten. Im Datenblatt habe ich gelesen, daß 
man den Sensor nach dem löten bei >74%RH für mindestens 24 Stunden 
lagern soll.
Über Nacht habe ich nun einen Sensor mit einem feuchten Lappen in eine 
Box gepackt, hat aber bisher keine Auswirkungen gehabt, sind allerdings 
auch noch keine 24 Stunden.
Da sich aber auch die nicht gelöteten Sensoren so verhalten, trocknen 
die Sensoren von allein aus?

Vielleicht hat jemand einen Tipp, mir ist momentan nicht ganz klar, ob 
es an den Sensoren liegt oder vielleicht doch am code der Library. Da 
die Temperatur aber einwandfrei gelesen wird vermute ich eher die 
Sensoren.

Danke für die Hilfe

Gruß Robert

[Andreas K. (a-k)]

Ich verwende für die SHT11 und FOST02 nicht die Lib sondern eigenen 
Code. Damit geht es jedenfalls. Die Sache mit der feuchten Lagerung nach 
deom Einlöten kann vielleicht die Genaugkeit beeinflussen, aber nicht 
die Funktion selbst.

Kontrolliere mal die Rohdaten, also vor der Umwandlung in %RH. Auch bei 
der Temperatur. Wenn da beispielsweise auch 0 rauskommt, dann hat das 
eher mit Hardware/Verschaltung oder Porteinstellungen zu tun.

Kannst ja mal das Schaltbild von Controller+Sensor verraten. Also von 
dem von dir real zusammengebauten Kram, keine Kopie aus irgendeiner 
Vorlage.

[Robert K. (r0bert)]

Hallo Andreas,
anbei ist ein Schaltplan den ich jetzt schnell erstellt habe. Die 
Beschaltung des Atmegas habe ich mir gespart, der sitzt auf einem 
Pollin-Funkboard wo Reset usw natürlich beschaltet sind. Ich gehe vom 
Funkboard über den 40 Poligen Wannenstecker auf mein Steckbrett, wo LCD 
und der Sensor angeschlossen sind. Im prinzip ist die Beschaltung des 
LCDs wie im Tutorial, ich benutze auch den dortigen Code. Der Sensor 
benutzt auch die Pins wie in der Library eingetragen, habe da also 
nichts verändert. Beide Komponenten sind also auf Port D, sollte sich 
das etwa gegenseitig stören?
Auf PD5 und PD6 befinden sich auf dem Funkboard jeweils eine LED mit 270 
Ohm gegen Masse, ich hoffe die stören nicht, immerhin kann man so schön 
sehen, daß auf den Leitungen etwas passiert.
Leider bin ich mit meinen Kenntnissen noch nicht so weit, daß ich mir 
eigenen komplexen Code schreiben könnte. Ich muss erstmal verstehen wie 
das ganze mit dem LCD und dem Sensor genau funktioniert. Auch das 
Programmieren ist noch eine kleine Herausforderung, habe bisher noch 
nicht so viel damit gemacht.

[Robert K. (r0bert)]

Ich habe jetzt probehalber den Sensor auf Port C (PC0 und PC1) 
verschoben, das hat am Ergebnis jedoch nichts geändert.

[Andreas K. (a-k)]

Robert K. wrote:

> Auf PD5 und PD6 befinden sich auf dem Funkboard jeweils eine LED mit 270
> Ohm gegen Masse, ich hoffe die stören nicht,

Da hast du die Antwort. Wenn Daten vom Sensor gelesen werden, ist einzig 
der 10K Widerstand an DATA dazu ausersehen, die Leitung in Richtung 5V 
zu ziehen um eine "1" zu liefern. Dass er das gegen eine LED mit 270 Ohm 
nicht kann liegt auf der Hand.

[Robert K. (r0bert)]

Hallo Andreas,
Danke für die Erklärung, das leuchtet ein. Allerdings verstehe ich dann 
nicht, warum das Auslesen der Temperatur dann funktioniert.
Und da ich den Sensor nun auf den Port C verschoben habe (hier ist 
nichts anderes auf der Leitung) und sich nichts geändert hat, dürfte das 
Problem woanders liegen.

[Andreas K. (a-k)]

Nochmal die Frage: Wie sehen die Rohdaten aus?

[Robert K. (r0bert)]

Ich habe nun die Plausibilitätsprüfung aus der Library auskommentiert, 
bekomme jetzt also rh_true unverändert raus. Den Wert übergebe ich dann 
my_uitoa (https://www.mikrocontroller.net/articles/Festkommaarithmetik) 
und schreibe den String dann auf das LCD.
Bei der Temperatur erhalte ich 211, was 21,1 Grad entsprechen sollte. 
Der Wert der Luftfeuchtigkeit wird mit 4294967207 angezeigt, ändert sich 
auch um einige tausend wenn man den Sensor anhaucht(sinkt bei steigender 
Feuchtigkeit).

[Andreas K. (a-k)]

Unter Rohdaten verstehe ich die Daten direkt aus dem Sensor. Ohne 
Umrechnung in Grad, Prozent oder Taupunkt.

[Andreas K. (a-k)]

Was die Lib angeht - ich konnte auf die Schnelle nur die V2 finden.

[Robert K. (r0bert)]

Hi Andreas,
vielen Dank für deine Gedult und Hilfe!
Sorry, wenn man schon um Hilfe bittet sollte man es den Leuten so 
einfach wie möglich machen, hier der Link:
Beitrag "Feuchtigkeitssensor FOST02A gibt nur 1en aus"

Ich denke ich habe nun die Rohdaten, wie gesagt ich bin noch Anfänger 
und musste mir nochmal einiges durchlesen um wenigstens etwas 
durchzublicken (union, pointer, addressoperator), das erschwert die 
Sache natürlich etwas. Ja, vielleicht sollte ich mich erst noch mit 
einfacheren Sachen befassen, bevor ich solche komplexeren Themen angehe 
;)

Also folgende Werte habe ich momentan:
Temperatur=6235
Luftfeuchtigkeit=1030
Ich hoffe die Werte passen. Meine main funktion sieht so aus:

int main(void) {

        lcd_init();

        sht_value humi_val,temp_val;
        float dew_point;
        float volatile temp, humi;     //- debug
        unsigned char error,checksum;
        unsigned int i;
        error = sht_softreset();

        while(1) {
                error=0;
                error+=sht_measure( &humi_val,&checksum,HUMI);  //measure humidity
                error+=sht_measure( &temp_val,&checksum,TEMP);  //measure temperature
                if(error!=0) sht_connectionreset();                 //in case of an error: connection reset
                else
                {

//                      sht_raw_to_physical(&humi_val, &temp_val);
                        humi = humi_val.i;
                        temp = temp_val.i;
                        dew_point=calc_dewpoint(humi_val.f,temp_val.f); //calculate dew point

                        char c_temp[13];
                        char c_humi[13];
                        char c_dew[13];

                        my_uitoa(temp, c_temp);
                        my_uitoa(humi, c_humi);
                        my_uitoa(dew_point, c_dew);

                        set_cursor(0,1);
                        lcd_string(c_temp);
                        lcd_string(" ");
                        lcd_string(c_humi);
                        lcd_string(" ");
                        lcd_string(c_dew);

                        //printf("temp:%5.1fC humi:%5.1f%% dew point:%5.1fC\n",temp_val.f,humi_val.f,dew_point);
                }

                //----------wait approx. 0.8s to avoid heating up SHTxx------------------------------
                for (i=0;i<40000;i++) {_delay_us(10);}     //(be sure that the compiler doesn't eliminate this line!)
                //-----------------------------------------------------------------------------------

        }
        return 0;
}

Ist also fast identisch mit dem Beispiel aus der Lib, habe nur 
sht_raw_to_physical auskommentiert und bei den beiden nächsten Zeilen .f 
in .i geändert. (Bei .f liefert er nur Null zurück)

[Andreas K. (a-k)]

Ein Sensorwert von 1030 übersetzt sich mir in ca. 35%RH. Das scheint mir 
für das heutige Wetter realistisch, zumal ich grad ähnliche Werte 
angezeigt kriege.

Wenn nach der Umrechnung Blödsinn rauskommt, dann ist der Sensor 
unschuldig und das Programm Unfug.

Es gibt einige Gründe, warum ich die libsht nicht verwende. Deren 
Verwirrspiel mit Parametrisierung über unions lädt zu Fehlern geradezu 
ein (du wärst auch nicht der Erste der darüber stolpert). 
Floating-Point-Rechnung vermeide ich bei kleinen Controller-Anwendungen 
soweit möglich. Und der Code ist in meinen Augen ziemlich schlecht 
lesbar - wobei das freilich ein sehr subjektives Kriterium ist.

[Andreas K. (a-k)]

Code für SHT11, der deutlich besser aussieht und eine recht pfiffige 
Umrechnung enthält, findet sich in 
Beitrag "Programmierung des SHT11 mit dem AT90S4433".

Anbei mein SHT11/FOST02-Codemodul. Kann in beiden Auflösungsmodi der 
Sensoren arbeiten.

[Robert K. (r0bert)]

Hallo Andreas,
ich habe mir nun nochmal das Datenblatt geschnappt und bischen mit dem 
Taschenrechner gerechnet. Laut der dort abgebildeten Kurve entsprechen 
die momentan gemessenen ca. 1100 etwa 35%.
Die Lib geht davon aus, daß der Sensor einen 8 Bit Wert zurückgibt, bei 
den Zahlen würde tatsächlich ein negativer Wert herauskommen. Ich habe 
nun die defines und Konstanten fest für 12 Bit verdrahtet und zack, auf 
dem Display habe ich nun 36% :)
Komisch finde ich das irgendwie schon, denn hier im Forum bin ich auf 
einige Meldungen gestoßen, daß der Sensor angeblich nur 8 Bit bei der 
Luftfeuchtigkeit kann, und die Lib würde dieses auch bestätigen, nur der 
Sensor weiß davon wohl nichts ;)
Also nochmal vielen Dank für deine Mühe und Unterstützung, du hast mir 
geholfen das Problem einzukreisen und gelernt habe ich auch einiges 
dabei.
Den Code für den sht11 werde ich auch ausprobieren, aber ich glaube für 
heute  mache ich erstmal "Feierabend"...

[Andreas K. (a-k)]

Der Sensor kann beide Auflösungen. Zumindest im Prinzip. Ob in der hohen 
Auflösung der Wurm drin ist (man also beim abkupfern geschlampt hat ;-), 
oder Hope nur ehrlich genug ist, diesen Modus mangels dazu passender 
Genauigkeit garnicht erst zu dokumentieren, das weiss ich nicht.

Jedenfalls muss man dem Teil erst einmal mitteilen, dass der niedrig 
auflösende Modus gewünscht ist, d.h. man muss das entsprechende Bit 
setzen. Sonst kriegt man den hoch auflösenden Modus.