Das mit dem inkrement abhängig vom 9ten Bit (also dem MSB des "TempL") rundet den halb Grad genauen Wert auf einen ganzzahlig genauen. Statt des increment könntest Du ebenso eine ",5"-Anzeige an oder ausschalten. Da Du die aber nicht hast, wird gerundet. Durch das runden bleibt deine Anzeige immer noch bei ganzen °C, allerdings zeigt es jetzt bei 4,7°C (was der Sensor als 4,5°C mißt) eben korrekt gerundete 5°C an, und nicht 4°C.
Wenn Du aber mittelst, also n Werte integrierst, und Durch n teilst, Muß die Variable die die Summe aufnimmt breiter als ein Byte sein. Warum? Das theoretische Maximum des Sensors liegt bei 125°C, der Sensor liefert dann 01111101bin TempH und 00000000bin TempL.
Selbst wenn Du das 9te Bit wegläßt/vorher rundest, würdest Du mit 16 möglichen 125-Werten aufintegriert auf 16*125=2000 kommen -
binär also (01111101bin<<4)=011111010000bin. Wären also 11 Bit breite Zahlen nötig. Also 2 Bytes. Da Dir dann aber eh 16bit zur Verfügung stehen, kannst Du auch das 9te Bit in den Mittelwert einfliessen lassen - dann wäre 125 (rechtsorientiert und mit 1bit=0,5) dargestellt 00000000.11111010, wenn der 16mal integriert wurde (also 2000=max) 00001111.10100000 - du könntest sogar 256 Werte mitteln.
Da Dein Ergebnis halbe °C darstellt, ist es nicht durch 16 zu teilen, sondern durch (2*16), genaugenommen ist also fünfmal rechtszuschieben.
Dabei ist das zuletzt rausgeschobene Bit für die Rundung auf ganze Grad relevant, es gibt aber auch einen anderen Trick, der hier angewendet werden kann:
Es wird einfach vor dem 5fach-Schieben "0,5" addiert (also 00010000bin bzw 16dez), diesen Trick hatte Dino schonmal irgendwo mal erwähnt.
Die Mittelung hilft Dir aber auch nicht immer gegen Deine schwankenden Werte - ok, durch die reduzierte Aktualisierungsfrequenz der Anzeige nimmst Du das nicht mehr so wahr, auf der Anderen kannst Du zufällig entsprechende Werte innerhalb der schwankenden Temperatur treffen, oder nicht.
Die Frage die Du Dir eigentlich stellen mußt ist, warum der Sensor ständig schwankende Temperaturen erkennt/digitalisiert, zwischen 2 aufeinanderfolgenden(?) Samples, und um ein bis zwei (?) volle Kelvin. Das wären ja die letzten 3 der 9 bits...
Ich hab's ja schon mehrfach geschrieben: den Sensor mal lichtgeschützt und isoliert messen lassen, sinnigerweise das 9bit-Ergebnis über viele Werte loggen (über die serielle Schnittstelle an den PC), und die Schwankungen sichtbar machen.
Entweder Du liest den Sensor etwas langsamer aus als alle 0,75s (timerbasiert, um garantiert jedesmal einen neu digitalisierten Wert aufzuzeichnen), oder Du pollst das "Messung fertig Flag" aus dem Control-Register des Sensors, was mir in Verbindung mit dem Dauerlauf aber noch nicht ganz klar ist/herauszufinden wäre. (Also ggf Einzelschußmodus, pollen, Schuß auslösen, Wert lesen/verarbeiten/übertragen, pollen, ...)
Ein integrierter Sensor, der mit 9 bit auf'n halbes Kelvin genau mißt, und dabei durch Rauschen über 2 Kelvin (3 Bit) hinweg schwankt, erscheint mir nicht plausibel. Wenn die Ergebnisse dermaßen schwanken, werden auch die Temperature auf der Sensoroberfläche (vielleicht auch der Beinchen) schwanken...
Wenn Du aber mittelst, also n Werte integrierst, und Durch n teilst, Muß die Variable die die Summe aufnimmt breiter als ein Byte sein. Warum? Das theoretische Maximum des Sensors liegt bei 125°C, der Sensor liefert dann 01111101bin TempH und 00000000bin TempL.
Selbst wenn Du das 9te Bit wegläßt/vorher rundest, würdest Du mit 16 möglichen 125-Werten aufintegriert auf 16*125=2000 kommen -
binär also (01111101bin<<4)=011111010000bin. Wären also 11 Bit breite Zahlen nötig. Also 2 Bytes. Da Dir dann aber eh 16bit zur Verfügung stehen, kannst Du auch das 9te Bit in den Mittelwert einfliessen lassen - dann wäre 125 (rechtsorientiert und mit 1bit=0,5) dargestellt 00000000.11111010, wenn der 16mal integriert wurde (also 2000=max) 00001111.10100000 - du könntest sogar 256 Werte mitteln.
Da Dein Ergebnis halbe °C darstellt, ist es nicht durch 16 zu teilen, sondern durch (2*16), genaugenommen ist also fünfmal rechtszuschieben.
Dabei ist das zuletzt rausgeschobene Bit für die Rundung auf ganze Grad relevant, es gibt aber auch einen anderen Trick, der hier angewendet werden kann:
Es wird einfach vor dem 5fach-Schieben "0,5" addiert (also 00010000bin bzw 16dez), diesen Trick hatte Dino schonmal irgendwo mal erwähnt.
Die Mittelung hilft Dir aber auch nicht immer gegen Deine schwankenden Werte - ok, durch die reduzierte Aktualisierungsfrequenz der Anzeige nimmst Du das nicht mehr so wahr, auf der Anderen kannst Du zufällig entsprechende Werte innerhalb der schwankenden Temperatur treffen, oder nicht.
Die Frage die Du Dir eigentlich stellen mußt ist, warum der Sensor ständig schwankende Temperaturen erkennt/digitalisiert, zwischen 2 aufeinanderfolgenden(?) Samples, und um ein bis zwei (?) volle Kelvin. Das wären ja die letzten 3 der 9 bits...
Ich hab's ja schon mehrfach geschrieben: den Sensor mal lichtgeschützt und isoliert messen lassen, sinnigerweise das 9bit-Ergebnis über viele Werte loggen (über die serielle Schnittstelle an den PC), und die Schwankungen sichtbar machen.
Entweder Du liest den Sensor etwas langsamer aus als alle 0,75s (timerbasiert, um garantiert jedesmal einen neu digitalisierten Wert aufzuzeichnen), oder Du pollst das "Messung fertig Flag" aus dem Control-Register des Sensors, was mir in Verbindung mit dem Dauerlauf aber noch nicht ganz klar ist/herauszufinden wäre. (Also ggf Einzelschußmodus, pollen, Schuß auslösen, Wert lesen/verarbeiten/übertragen, pollen, ...)
Ein integrierter Sensor, der mit 9 bit auf'n halbes Kelvin genau mißt, und dabei durch Rauschen über 2 Kelvin (3 Bit) hinweg schwankt, erscheint mir nicht plausibel. Wenn die Ergebnisse dermaßen schwanken, werden auch die Temperature auf der Sensoroberfläche (vielleicht auch der Beinchen) schwanken...
