Umrechnung Ergebnis DS18B20

Erhard S. schrieb:
> Außer eine Umrechnungstabelle anzulegen, fällt mir momentan nichts ein

Ist das dein voller Ernst??? Abziehen lernt man in der Grundschule.

Was hast du denn vor?
Der DS18x20 gibt doch per OneWire direkt einen Temperaturwert aus. Das 
ist die tatsächliche Temperatur am Sensor (im Rahmen der Toleranzen).
Was soll denn da linear werden? Wenn dir die Aussentemperatur nicht 
passt kannst du den Messwert natürlich beliebig verrechnen damit die 
Kurve besser aussieht. Oder was soll das werden?

Oliver S. schrieb:
> Der DS18x20 gibt doch per OneWire direkt einen Temperaturwert aus.

Nein, das tut er nicht.
Er gibt den Temperaturwert in 0.0625°C Schritten aus.
Schau mal in das Datenblatt. Auf S.6 wird es beschrieben.

Andreas B. schrieb:
> Oliver S. schrieb:
>> Der DS18x20 gibt doch per OneWire direkt einen Temperaturwert aus.
> Nein, das tut er nicht.
> Er gibt den Temperaturwert in 0.0625°C Schritten aus.

Was soll der Unterschied hierbei sein?

Sebastian schrieb:
> Also 880 draufaddieren?
Das mit den Rechnen üben wir aber noch mal.

Wolle G. schrieb:
>> Er gibt den Temperaturwert in 0.0625°C Schritten aus.
>
> Was soll der Unterschied hierbei sein?
Der Unterschied ist, daß der Wert durch 16 dividiert werden muß, um die 
T in °C zu erhalten.

Andreas B. schrieb:
> Sebastian schrieb:
>
>> Also 880 draufaddieren?
>
> Das mit den Rechnen üben wir aber noch mal.

Wer? -55°C abziehen ist gleich wie 880 addieren.

(prx) A. K. schrieb:
> Wer? -55°C abziehen ist gleich wie 880 addieren.
Da wird nichts addiert oder abgezogen. Die Darstellung ist ein Integer 
mit Vorzeichen in 1/16°C. Guck doch mal ins Datenblatt.
Du kannst natürlich 880 addieren um auf positive Zahlen zu kommen. Das 
hilft aber erst mal wenig. Negative Temperaturen sind nun mal negativ. 
Die Vorzeichenarithmetik behält man sinnvollerweise gleich bei.

Edit: Sorry, gerade gesehen, daß der TO ja -55°C als 0 haben will, wozu 
auch immer. So gesehen muß er also die 55°C addieren.
Mir ging es um die Aussage daß der 18B20 die T direkt in °C ausgibt.

Wenn er bei -55°C den Wert 0 haben will:
X - -55°C = X + 55°C = X + 55*16 = X + 880

In welcher Einheit er es haben will, ob ganzen Grad oder Sechzehntel, 
liess er offen.

Wolfgang schrieb:
> Andreas B. schrieb:
>> Wolle G. schrieb:
>>>> Er gibt den Temperaturwert in 0.0625°C Schritten aus.
>>>
>>> Was soll der Unterschied hierbei sein?
>> Der Unterschied ist, daß der Wert durch 16 dividiert werden muß, um die
>> T in °C zu erhalten.
>
> Das LSB hat einen Wert von 2^-4°C, so wie es im Datenblatt auf S.6
> beschrieben ist. Das ist eine (binäre) Festkommadarstellung.
> Der Nutzer kann damit machen, was er will. Wenn er diese
> Festkommadarstellung fälschlicherweise als Ganzzahl interpretiert, muss
> er natürlich durch 16 teilen. Das ist dann sein Problem ;-)

Man könnte es zwar als Haarspalterei bezeichnen, aber durch Weglassen 
kann man den Sinn entstellen.
Die Frage:
>>> Was soll der Unterschied hierbei sein?
sollte allerdings auch nicht  zu ernst genommen werden. Es sollte nur 
zum Ausdruck gebracht werden, dass es im Prinzip egal ist, ob eine 
Temperatur mit einer Auflösung mit 0,0625K angegeben wird
oder  man sagt:
>>Der DS18x20 gibt doch per OneWire direkt einen Temperaturwert aus.
Temperatur bleibt Temperatur

Erhard S. schrieb:
> Manchmal sieht man den Wald vor lauter Bäumen nicht mehr und dreht sich
> im Kreis.
Ist das Problem mit der Rechnerei zu den negativen Temperaturwerten 
zwischenzeitlich gelöst?

Wolfgang schrieb:
> Wolle G. schrieb:
>> Ist das Problem mit der Rechnerei zu den negativen Temperaturwerten
>> zwischenzeitlich gelöst?
>
> Was soll man bei den negativen Temperaturen rechnen. Der DS18B20 liefert
> 12-Bit Zweierkomplement (aufgebohrt auf 16Bit)

Man will ja nicht all zu dumm sterben, aber seinen Horizont erweitern.
Ein kleines Beispiel wäre hilfreich.
z. B. Ein DS18B20 hat den Wert 0xFF48 ausgegeben. Der Temperaturwert 
soll auf einer Anzeige ausgegeben werden. Wie könnte man vorgehen?

Andreas B. schrieb:
> Der Unterschied ist, daß der Wert durch 16 dividiert werden muß, um die
> T in °C zu erhalten

Und das ist doch schon linear. Keine e-funktion oder sonst was

(prx) A. K. schrieb:
> Wenn er bei -55°C den Wert 0 haben will:

Was schon mal SEHR fragwürdig ist. Was soll der Käse?

Ok, viele Leute haben ein Problem mit Festkommaarithmetik und 1/16° 
Auflösung. Das kann man aber leicht durch *10/16 in 0,1°C Auflösung 
umrechnen, wenn einem das besser gefällt.

Falk B. schrieb:
> Was schon mal SEHR fragwürdig ist. Was soll der Käse?

Vielleicht mag er Vorzeichen nicht so. Könnte ich beispielsweise bei 
einem 8051 verstehen, der tut sich bei Vergleichen mit Vorzeichen 
schwerer. 8-Bit PICs wohl auch.

(prx) A. K. schrieb:
> Vielleicht mag er Vorzeichen nicht so. Könnte ich beispielsweise bei
> einem 8051 verstehen, der tut sich bei Vergleichen mit Vorzeichen
> schwerer. 8-Bit PICs wohl auch.

Und das anno domini 2021 . . .

(prx) A. K. schrieb:
> Könnte ich beispielsweise bei
> einem 8051 verstehen, der tut sich bei Vergleichen mit Vorzeichen
> schwerer.

Das geht doch ganz einfach mit dem OV-Bit:
"When subtracting signed integers, OV indicates a negative number 
produced when a negative value is subtracted from a positive value, or a 
positive result when a positive number is subtracted from a negative 
number."

Falk B. schrieb:
> Und das anno domini 2021 . . .

Ja, das hatte sich Intel auch nicht träumen lassen. War der 8051 doch 
genau wie der 8088 bloss eine Zwischenstation auf dem Weg zu 
Grossartigerem. Denn eigentlich sollte deren MCS-96 den Controller-Markt 
abräumen, aber den kennt heute kein Aas mehr.

Peter D. schrieb:
> Das geht doch ganz einfach mit dem OV-Bit

Im Prinzip richtig. Es fehlt aber der Vergleichsbefehl mit Vorzeichen, 
der die nötigen Informationen nutzt, also Sign XOR Overflow. Das ist 
kein Beinbruch, es gibt Umgehung z.B. per Komplementbildung. Aber ist 
halt etwas umständlicher.

Komplementbildung würde das auch hier erreichen. Der gesamte 
Wertebereich wäre dann vorzeichenfrei vergleichbar, nur wäre 0 nicht 
-55°C.

(prx) A. K. schrieb:
> Ja, das hatte sich Intel auch nicht träumen lassen. War der 8051 doch
> genau wie der 8088 bloss eine Zwischenstation auf dem Weg zu

Nicht hält so lange wie ein Provisorium ;-)

(prx) A. K. schrieb:
> Im Prinzip richtig. Es fehlt aber der Vergleichsbefehl mit Vorzeichen

... Sprungbefehl ...

Wolfgang schrieb:
> Als signed Int Wert interpretiert ist das -184. Wenn der Wert vom
> DS18B20 kommt, wird das wohl bedeuten, dass der eine Temperatur von
> -184/16=-11.5°C gemessen hat.
Danke. Das hat funktioniert mit einer kleinen Änderung, aber mit einer 
großen Wirkung
    -183/16 erzeugt  -11.0000               (falsch)
Mit -183/16.0 wird   -11.5625 angezeigt     (richtig)
Es geht auch -183/16. (also nur das Komma verwenden)
Verwendet wurde IAR.
Welche Erklärung könnte es dafür geben?

Programmschnipsel:
void  datenrx_ausgeben(void)
  {
   char vers[9],z,c;
   float temp;
   signed int negative_daten = 0xFF47;           // 16Bit DS18B20
   temp = negative_daten/16.0;
   lcd_write_command(LCD_CMD_CURSOR_LA,165);     //FKA LC7981;
            // 26=Zeilenanfang   2.Zeile --> 26 Zeichen pro Zeile
   lcd_write_command(LCD_CMD_CURSOR_HA,0);
   sprintf(vers,"%#3.4f",temp);
   for (z=0; z<8;z++)
   {
   c=vers[z];
   lcd_write_command(LCD_CMD_WRITE_DATA, c);
   }
   }

Wolle G. schrieb:
> Danke. Das hat funktioniert mit einer kleinen Änderung, aber mit einer
> großen Wirkung
>     -183/16 erzeugt  -11.0000               (falsch)
> Mit -183/16.0 wird   -11.5625 angezeigt     (richtig)
> Es geht auch -183/16. (also nur das Komma verwenden)
> Verwendet wurde IAR.
> Welche Erklärung könnte es dafür geben?

Ja was wohl? Die erste Zeile ist eine reine Integerechnung, das Ergebnis 
hat keine Nachkommastellen. Allerdings wird das Erbenis dann in float 
konvertiert, weil temp vom Typ float ist.  Die 2. Rechnung wird mit 
Fließkomma gerechnet, da dort /16.0 steht. Beide Ergebnisse sind 
richtig, nur dein Verständnis von C ist es nicht.

Falk B. schrieb:
> ....,nur dein Verständnis von C ist es nicht.

Das ist ja schon lange bekannt. Deshalb auch die Frage von mir.
Trotzdem vielen Dank für die Erklärung.

Wolle G. schrieb:
> Das ist ja schon lange bekannt. Deshalb auch die Frage von mir.
> Trotzdem vielen Dank für die Erklärung.

Für so eine einfache Sache braucht es keine Fließkommarechnung, da 
reicht Festkommaarithmetik für minimalen Resourcenbedarf. Man 
rechnet auf 0,1°C um und gibt es passend aus. Oder man rechnet es gleich 
auf volle °C um, das reicht für viele Anwendungen locker aus.

1

int temp;

2

temp = data_DS18B20 * 10/16;  // Temperatur in 0,1°C Auflösung

3

sprintf(vers, "%3d.%1d", temp/10, abs(temp%10));

Falk B. schrieb:
> Man rechnet auf 0,1°C um und gibt es passend aus. Oder man rechnet es
> gleich auf volle °C um, das reicht für viele Anwendungen locker aus.
Welche Auflösung man verwenden sollte, das ist m.M. abhängig von der 
jeweiligen Anwendung.
z. B. : Betrieb eines digitalen PI(D) an einem Heizkörpermotorventil.
Diese Art von Spielzeug hatte ich im letzten Winter in Betrieb. Dabei 
wurde für die Regelfunktion die volle Auflösung genutzt, wobei der 
Temperaturwert des DS18B20 für den Regler als Ganzzahl genutzt wurde, 
während bei der Temperaturanzeige nur 1 Nachkommastelle nötig ist.
Einschätzung des Spielbetriebes: Für eine optimale Regelung der 
Raumtemperatur unter Verwendung der aktuell verfügbaren Ventilunterteile 
ist noch Luft nach oben, da die Ventilkennlinie Q =(f) Hub nicht zur 
Heizkörperkennlinie passt. Schon eine Hubänderung von einem 1/100mm 
führte teilweise zu einem schlechten Regelverhalten. Aber das ist ein 
anderes Thema.

Wenn man die Temperatur grafisch in ausreichend hoher Auflösung 
darstellt, kann es sinnvoll sein, bei 1/16 zu bleiben. Durch eine 
Umrechnung in 1/10 können kleine Artefakte in der Grafik entstehen.

Wolfgang schrieb:
> Eine Frage: Wie kommst du von 0xFF48 auf -183?

> -183/16 ist immer noch -11,4375
Das stimmt natürlich.
Ich habe nur das angezeigte Ergebnis der Funktion:
void  datenrx_ausgeben(void)
abgeschrieben und den Wert -183 „erfunden“.
Eigentlich sollten nur die  unterschiedlichen Ergebnisse mit /16 und 
/16.0dargestellt werden, wofür ich keine Erklärung hatte.

(prx) A. K. schrieb:
> Wenn man die Temperatur grafisch in ausreichend hoher Auflösung
> darstellt, kann es sinnvoll sein, bei 1/16 zu bleiben. Durch eine
> Umrechnung in 1/10 können kleine Artefakte in der Grafik entstehen.
Wie Abkühlkurven mit DS18B20 bei voller Auflösung tatsächlich aussehen 
können, zeigen die Diagramme unter
Beitrag "Re: DS18B20 Sensor"
Achtung: zwei Kurven sind vertauscht ausgewiesen

Thomas S. schrieb:
> Kann es sein, dass das Zauberwort 'OFFSET' heist?

Was meinst Du, bezogen auf DS18B20, damit?