Announcement: there is an English version of this forum on 
Wie interpretiert ihr die Angabe zu gain? Ausgelesen habe ich 0x2C: 0x85 0x2D: 0xFD (das ist klar)
Angehängte Dateien:
-
cal_bytes.PNG
12,4 KB, 177 Downloads
H.Joachim S. schrieb: > Wie interpretiert ihr die Angabe zu gain? Anders. Konkreter: garnicht. Da gibt es nix zu "interpretieren", man kann direkt mit den Werten rechnen, exakt so wie sie in der signature row stehen. Genau deswegen stehen die nämlich genau so da drin, wie sie drin stehen, optimiert darauf, dass man mit möglichst geringem Aufwand an Arithmetik zu einem möglichst exakten Ergebnis kommt. Die Erklärung der Binärformate der Kalibrierwerte dient nur zu einem Zweck: es ergibt sich daraus das Binärformat des Endergebnisses der Rechnung. Das muss man nämlich kennen, um dieses Ergebnis richtig interpretieren zu können. Denn das (und nur das) bedarf einer Interpretation. Spannend ist allerdings eine Sache: ist der Offset vor dem Skalieren anzuwenden oder danach? Mathematisch wäre beides möglich, welche Variante hier gewählt wurde, steht nicht in dem Auszug, den du gepostet hast, aber vermutlich auf der in note 2) zur Lektüre empfohlenen Seite 143 des Datenblattes. Ich hätte die wirklich gern gelesen, allein: in deiner grenzenlosen Weisheit hast du es für überflüssig gehalten, den exakten Typ des Tinys anzugeben, scheinbar glaubst du, es gäbe nur einen Einzigen. Dem ist aber überraschenderweise definitiv NICHT so! Da ich nun aber keinen Bock haben, einige Dutzend Datenblätter zu durchforsten, bleibt's halt, bis ich selber mal das Problem habe, dann kann ich immer noch diese Seite 143 lesen und dann hoffentlich den Offset richtig anwenden...
Ich kann diesbezüglich leider nichts im Datenblatt finden, der ATtiny2313A hat nicht einmal einen Temperatursensor... Ohhh, du redest von anderen ATtiny? Für konkrete Hilfe wäre ein konkreter Typ sicherlich hilfreich. ;) Um trotzdem noch etwas hilfreiches beizutragen: (reine Vermutung da ich nicht im Datenblatt nachsehen kann weil du den genauen Typ ja nicht angegeben hast)
1 | gain = calibration_byte / 255 |
In deinem konkrete beispiel also
1 | gain = (0x85 = 133) / 255 = 1,0390625 |
Stefan R. schrieb: > Um trotzdem noch etwas hilfreiches beizutragen: (reine Vermutung da ich > nicht im Datenblatt nachsehen kann weil du den genauen Typ ja nicht > angegeben hast) > gain = calibration_byte / 255 Das ist nun definitiv falsch, soviel zumindest gab ja schon der gepostete Auszug des DB her... Tipp: Das Binärformat ist so gewählt, dass sich ein Faktor zwischen 0 .0 und knapp unter 2.0 ergeben kann, wenn man den gesamten möglichen Wertebereich des Kalibrierungsbytes überstreicht. Sprich: der Divisor in deiner Formel muss 128 heißen. Aber wie schon gesagt: Es ist völliger Unsinn, an den Kalibrierungswerten rumzuwerkeln. Die sind in einem Format abgelegt, dass es erlaubt, mit möglichst wenig rechenzeitfressenden Operationen vom ADC-Wert zum Endwert zu kommen. Erst der ist dann zu "interpretieren". Bei dem Binärformat des Gain-Kalibrierungswertes bedeutet das: Das Ergebnis der Multiplikation von ADC-Wert und Gain-Konstante ist um ein Bit nach links zu schieben, wenn man den Integer-Teil des Ergebnisses und den fraktionalen Teil in getrennten Bytes haben möchte. Noch ein Tipp: längst nicht immer ist das überhaupt nötig. Wenn die Temperatur z.B. wiederum nur in irgendeine Regelung als Faktor eingeht, muss man diese Schieberei nicht unbedingt machen. Das hängt dann wiederum von der Gleichung der Regelstrecke ab, ob das sinnvoll ist oder nicht. Meistens ist es das nicht, denn das fügt keine Information hinzu, erhöht aber die Anzahl der zu verarbeitenden Bits um eins. Kurz: Schwachfug.
Gestört hat mich "unsigned ... two's complement" (und dafür spielt es auch keine Rolle, um welchen Typ genau es geht. Aber zur allgemeinen Beruhigung: Tiny441). Mit A2D*133/128 Korrektur passt es erstaunlich gut zu den Ergebnissen eines LM75, zumindest im Bereich 15-40°. Mehr habe ich nicht getestet
H.Joachim S. schrieb: > Gestört hat mich "unsigned ... two's complement" (und dafür spielt es > auch keine Rolle, um welchen Typ genau es geht. Der Typ spielt in diesem Zshg. tatsächlich keine Rolle, der war nur nötig, um die vermaledeite Seite 143 aufstöbern zu können. Ist mir übrigens immer noch nicht gelungen. Ich hatte nämlich sowieso schon auf Tiny 441/841 getippt, allerdings sieht mein DB dazu einigermaßen anders aus als deins. Ich habe wohl noch die gute alte Atmel-Ware... Wie auch immer: > Mit A2D*133/128 Korrektur passt es erstaunlich gut zu den Ergebnissen > eines LM75 Und ist trotzdem sehr wahrscheinlich noch falsch. Hier kommt das "two's complement" in's Spiel, was dich (vollkommen zu Recht) irgendwie gestört hat, weil es eigentlich im Kontext einer "unsigned"-Zahl keinen Sinn ergibt. Hier aber wohl schon... Selbiges gilt auch für den Offset. Man beachte den Wertebereich: -127..+128: hoppla, wer da nicht stutzig wird, dem ist echt nicht zu helfen... Vermutlich ergibt sich bei dir nur durch die Kombination der beiden Fehler ein einigermaßen plausibles Ergebnis in einem engen Wertebereich der Temperatur. Um das wirklich einschätzen zu können, wäre aber eben diese Seite 143 so eminent wichtig. Denn es spielt für die Fehlerbetrachtung schon eine enorme Rolle, ob der Offset mit zu skalieren ist oder eben nicht...
Angehängte Dateien:
-
page143.PNG
34,5 KB, 114 Downloads -
Unbenannt.PNG
2,47 KB, 55 Downloads
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8495-8-bit-AVR-Microcontrollers-ATtiny441-ATtiny841_Datasheet.pdf Messwert habe ich im Moment stabile 286, was nach obiger Formel 286*133/128-3 294K=21°C ergibt und perfekt zur gegenwärtigen Temperatur passt. Sitzt auf der gleichen Platine wie der LM75, noch ohne nennenswerte Verlustleistung auf der Platine. Sinn des ganzen ist eigentlich, den LM75 überflüssig zu machen, habe noch nie was mit den internen Sensoren gemacht. Das mit den -127:+128 ist mir ehrlich gesagt nicht mal aufgefallen, sowas überliest man. Ich denke, dass das ein Doku-Fehler ist. Werde morgen mal ein paar weitere Platinen aufbauen und schauen wie das dann aussieht.
:
Bearbeitet durch User
c-hater schrieb: >> gain = calibration_byte / 255 > > Das ist nun definitiv falsch, soviel zumindest gab ja schon der > gepostete Auszug des DB her... Stimmt - natürlich sollte es 128 anstelle von 255 lauten. Die 1,0390625 ergeben sich auch nur wenn man mit 128 und nicht 255 rechnet.
Thread beobachten
Seitenaufteilung abschalten