Geschätztes Forum,
nach einer Messung (Register ctrl_meas, 0x74, Set mode<1:0> to 0b01)
werden folgende Registerinhalte gelesen:
Register CONFIG: 0x1c (Filter)
Register TEMP_xlsb: 0x30, 0xc0, 0x90, 0x20... nach jeder Messung anders
Register TEMP_msb: 0x79 (bei konstanter Temperatur sabil)
Register TEMP_lsb: 0x30 (bei konstanter Temperatur sabil)
Temperaturwert Umgerechnet auf dezimal: 0x7930 => 31024
Momentane Raumtemperatur: ca.23 Grad
31024 hat nicht sehr viel mit 23 Grad zu tun.
Frage : Muss der Tempeaturwert noch umgerechnet werden?
Im Datenblatt Pkt 3.3.1 steht nichts dazu geschrieben.
Noch ein paar Worte zum ASM-Program für den 8Mhz getakteten ATmega8.
Kurz nach Programmstart wird der TWI/i2C Bus nach Sklaven durchsucht
0x3c (OLED) 0x77 (BME680) sollten gefunden werden.
Zusätzlich wird explizit nach dem BME680 und nach seiner ID (0x61)
gesucht und ein Software-Reset im BME680 durchgeführt.
Wichige Register ausgelesen und der Inhalt im SRAM abgelegt.
Momentan ist der AVR zu 52% belegt.
Auf die TWI/i2C Bus-Widerstände kann ggf. verzichtet werden, Pull-Up
Widerstände von SCL und SDA sind aktiviert.
Bernhard
> Ich finde mehrzeilige Titel für einen Fred großen Käse
Wer ist Fred?
Danke für den Hinweis, wir sind ein Land mit freier Meinungsäußerung.
Und warum findest Du es Käse? Zehn Punkte in Deiner Begründung würden
vollkommen genügen.
Du hast Recht, die nächsten Beiträgen werde ich im Betreff nur
noch " Frage " schreiben, damit jeder gleich weiß, um was es geht^^
Bernhard S. schrieb:> Temperaturwert Umgerechnet auf dezimal: 0x7930 => 31024
Wie kommst du auf die 0x7930?
Die unteren 4 Bit von temp_xlsb gehören nicht zum Temperaturwert
(DS 5.3.4.2)
Bernhard S. schrieb:> Frage : Muss der Tempeaturwert noch umgerechnet werden?> Im Datenblatt Pkt 3.3.1 steht nichts dazu geschrieben.
Ja, die Kalibrierkoeffizienten muss du vorher auslesen.
Die vom Hersteller im Treiber zum BME680 angegebene Routine für eine
Integerrechnung sieht wie folgt aus:
Wie Wolfgang schon schrieb musst man hier die Kalibrierdaten aus dem
Sensor auslesen und dann den ADC-Wert entsprechend Umrechen. Ich hab mir
jetzt mal das Datenblatt überflussweise angeschaut und finde es
interessant, dass anscheinend genau das im Datenblatt nicht erwähnt
wird. Wahrscheinlich hat man sich hier darauf verlassen, dass der
unbedarfte User sich andere Sensoren der BME-Serie anschaut. Mir ist der
BME680 neu, ich vermute aber mal dass das ein erweiterter BME280 ist und
dort findest du die Information wie man die Kalibrationsdaten ausliest.
Für den BME280 hab ich mal eine Libraray geschrieben in der du spicken
könntest, du findest sie unter http://www.github.com/Sylaina/BME280
Vielleicht hilft dir das weiter.
Wolfgang schrieb:> Gibt es irgend einen guten Grund, nicht den von Bosch auf der Seite zum> BME680 unter Software / Driver verlinkten Treiber zu benutzen oder> zumindest anzugucken?
Da musst du den Fragen, der den BME680 benutzen will ;)
M. K. schrieb:> Da musst du den Fragen, der den BME680 benutzen will ;)
Vielleicht stört es sich daran, dass Bosch Sensortec nicht für jeden µC
eine in Assembler geschriebene Library dazu liefert ;-)
Wolfgang schrieb:> Die vom Hersteller im Treiber zum BME680 angegebene Routine für eine> Integerrechnung sieht wie folgt aus:
1000 Dank, super, diese Formeln könnten weiterhelfen.
> Vielleicht stört es sich daran, dass Bosch Sensortec nicht für jeden µC> eine in Assembler geschriebene Library dazu liefert ;-)
Ein einfaches Berechnungsschema würde vollkommen genügen, enfach
dargestellt, so daß es auch Ingenieure verstehen können, unabhängig von
diversen Programmiersprachen und Rechenmaschinen.
Atmel schafft das doch auch z.B: ADC= VIN ⋅ 1024 / VREF
Nun muss ich mich leider erstmal mit Hochsprachen beschäftigen...
Fragen
"int64_t var1" wird damit eine 64Bit Variable definiert?
Wie ist diese Zeile zu deuten?
var1 = ((int32_t) temp_adc >> 3) - ((int32_t) dev->calib.par_t1 << 1);
var1 = (temp_adc : 4) - (calib.par_t1 x 2)
temp_adc= Temperatur-Rohdaten (32Bit) ?
calib.par_t1 scheint ein Kalibrierdaten-Bytes zu sein ?
M. K. schrieb:> Ich hab mir> jetzt mal das Datenblatt überflussweise angeschaut und finde es> interessant, dass anscheinend genau das im Datenblatt nicht erwähnt> wird.
Warum arbeitet Bosch nur so schluderhaft und oberfläch?
Bernhard S. schrieb:> "int64_t var1" wird damit eine 64Bit Variable definiert?
Damit wird die Variable "var1" als vorzeichenbehaftete 64Bit
(Ganzzahl-)Variable definiert.
> Wie ist diese Zeile zu deuten?> var1 = ((int32_t) temp_adc >> 3) - ((int32_t) dev->calib.par_t1 << 1);>> var1 = (temp_adc : 4) - (calib.par_t1 x 2)> temp_adc= Temperatur-Rohdaten (32Bit) ?
Ja, alles auf 32Bit Ganzzahl aufgebläht
> calib.par_t1 scheint ein Kalibrierdaten-Bytes zu sein ?
neim, vorzeichenlose 16 Bit, steht in
https://github.com/BoschSensortec/BME680_driver/blob/master/bme680_defs.h
Bernhard S. schrieb:> "int64_t var1" wird damit eine 64Bit Variable definiert?
Öhm...durch int64_t !?!
Bernhard S. schrieb:> var1 = ((int32_t) temp_adc >> 3) - ((int32_t) dev->calib.par_t1 << 1);
Ernsthaft jetzt. Jetzt mal ganz locker: Das sind eigentlich Basics. Das
sind nur Shift-Operationen und die sind dir im Jahr 2021 nicht geläufig?
Du schreibst immer noch in Assembler aber kannst so einfachste
Shift-Operationen nicht?
Hast du dir die Links mal angeschaut?
Bernhard S. schrieb:> Warum arbeitet Bosch nur so schluderhaft und oberfläch?
Echt jetzt? Dein Ernst? Das ist weder schluderhaft noch oberflächlich.
Wie Wolfgang es schon oben schrieb und auch verlinkte: Bosch stellt ja
sogar selbst Treiber zur Verfügung und da steht alles drin, ausführlich
beschrieben, müsste man halt mal lesen.
M. K. schrieb:> Ernsthaft jetzt. Jetzt mal ganz locker: Das sind eigentlich Basics. Das> sind nur Shift-Operationen und die sind dir im Jahr 2021 nicht geläufig?> Du schreibst immer noch in Assembler aber kannst so einfachste> Shift-Operationen nicht?> Hast du dir die Links mal angeschaut?
Nun werd mal nicht frech!
Wenn man diese Hochsprache nicht gelernt hat, können auch solche Basics
verunsichern.
Und was hat das mit 2021 zu tun?
Also in ein Datenblatt gehört auch eine Berechnungsgrundlage
(Mathematische Formel) wenn das Ergebnis daraus resultiert - Punkt. Auch
2021 ist das nicht anders als 1980! Da kann ich nicht mit Git Hub und
irgendwelchen Treibern in Hochsprachen kommen.
Das ist zwar hilfreich für einen Programmierer der genau in dieser
Hochsprache programmiert und führt auch schnell zu einem Ergebnis. Wie
Arduino.. Ich hoffe nur du musst sowas mal irgendwie zertifizieren. Dann
hast Spaß..
Steffen H. schrieb:> Also in ein Datenblatt gehört auch eine Berechnungsgrundlage> (Mathematische Formel) wenn das Ergebnis daraus resultiert - Punkt.
Du hast Dich ja beim BME280 schon ganz ordentlich ausgetobt. Respekt!
Beitrag "[ASM] BME280 mit OLed Display mit ATmega808"Steffen H. schrieb:>> calib.par_t1 scheint ein Kalibrierdaten-Bytes zu sein ?> Ja, und zwar Parameter T1
Parameter T1 finde ich im Datenblatt nicht nur S.19:
par_g1 0xED
par_g2 0xEB/0xEC
par_g3 0xEE
Steht "g" nicht für Gas?
Warum sind im Datenblatt nicht alle Register aufgelistet, ich such mir
den Wolf.
Dieser Therm sieht in C ganz einfach aus:
((int32_t) temp_adc >> 3)
in Assemler für eine 16Bit Zahl:
LSR R17 / :2
ROR R16
LSR R17 / :2
ROR R16
LSR R17 / :2
ROR R16
Die Kalibrierdaten sind im den Registern 89h.. A1h, E1h F0h, nur die
sind nicht im Datenblatt erwähnt, was mache ich falsch?
https://github.com/BoschSensortec/BME680_driver/blob/master/bme680.c
89h to A1h for calibration data 1 to 24
E1h to F0h for calibration data 25 to 40
Bernhard S. schrieb:> ws beduetet "dev->" ?>> ((int32_t) dev->calib.par_t1 << 1)
Im Programm wird für jeden BME680-Sensor eine Datenstruktur vom Typ
bme680_dev angelegt und diese Instanz heißt hier "dev". Darin gibt es
eine Struktur namens "calib" vom Typ bme680_calib_data. Und in dieser
Struktur gibt es par_t1 vom Typ uint16_t (16 Bit unsigned Integrer).
Diese Typen sind alle in bme680_defs.h beschrieben.
Das Ding oben beschreibt den Zugriff auf den Wert, der in par_t1 steht.
Und jetzt nimm dir mal ein C-Buch und mache dich mit ein paar Grundlagen
vertraut. Etwas C-Kenntnisse sollten heutzutage zumindest als passiver
Wortschatz existieren.
Steffen H. schrieb:> Da kann ich nicht mit Git Hub und> irgendwelchen Treibern in Hochsprachen kommen.
Öhm, doch. Es sind die Treiber des Herstellers. Was ist schlimm daran
wenn er die Source auf Github veröffentlicht? Wie gesagt, man müsste mal
halt rein schaun und lesen was da drin steht.
Steffen H. schrieb:> Also in ein Datenblatt gehört auch eine Berechnungsgrundlage
Oder ein Verweis wo noch Informationen zum Sensor zu finden sind...ups,
das ist ja im Datenblatt...da sind wir ja schon wieder beim Lesen,
verflixt noch eins.
M. K. schrieb:> Öhm, doch. Es sind die Treiber des Herstellers. Was ist schlimm daran> wenn er die Source auf Github veröffentlicht? Wie gesagt, man müsste mal> halt rein schaun und lesen was da drin steht.
Wenn dem so ist, dann braucht es ja demnächst keine Datenblätter mehr.
Und Bücher auch nicht. Gibt ja Wikipedia oder Google, was?
Ich sehe die Bibliotheken und Sources auf Git eher als Programmierhilfe
oder Zusatz. Never Ever aber als Datenblatt Ersatz!
Schon beim Datasheet des BME280 kam öfters die Disskusion über Bosch,
Datasheets und Werks-Studenten auf, die scheinbar ihre Bachelor Arbeit
dort geschrieben haben.
Denn die Berechnungen können vereinfacht werden, wenn man sich darüber
mal ein wenig Gedanken macht, ob man da wirklich 32bit (Float) oder
sogar 64bit (Double) zum rechnen braucht..
Aber wenn man keine Formel veröffentlicht, muss man mit den Aufgeblähten
Code auf Git zurechtkommen.
Tolle Aussichten sind das eben nicht. Und eine schreckliche Phillosophie
für Bosch - wie ich finde - eben auch.
So, und jetzt zerreißt mich :)
Steffen H. schrieb:> Wenn dem so ist, dann braucht es ja demnächst keine Datenblätter mehr.> Und Bücher auch nicht mehr.
Was meinst du wohl, wieso dir kein Bauteildistributor mehr Datenblätter
per Post zuschickt, auf die du zwei Wochen warten musst. Die Zeit ist
einfach vorbei. Auch Programme tippt keiner mehr seitenweise als
Hex-Code von totem Baum ab oder stanzt sie in Papierstreifen. Heutzutage
bekommst du die Datenblätter nur noch in Form von Dateien im PDF. In
einem Nachbar-Thread wird schon gemault, dass die nicht in XML daher
kommen. Da ist es doch wohl auch zumutbar, im der PDF-Datei auf einen
Link zu der zugehörigen Software zu klicken oder würde es dir besser
gefallen, wenn sie in der PDF-Datei eingebettet wäre.
Wolfgang schrieb:> Da ist es doch wohl auch zumutbar, im der PDF-Datei auf einen Link zu> der zugehörigen Software zu klicken oder würde es dir besser gefallen,> wenn sie in der PDF-Datei eingebettet wäre.
Hab ich es wirklich so undeutlich geschrieben?
Es ist echt super wenn es einen link zu fertigen Code / fertige
Bibliotheken gibt. Als Zusatz/Hilfe - Doch aber nicht zur Dokumentation!
Ich hab noch Mathe mit Formeln aus Thermen mit + - * / gelernt und nicht
durch eine Hochsprache, eingebettet in einem Code.
Steffen H. schrieb:> Ich hab noch Mathe mit Formeln aus Thermen mit + - * / gelernt und nicht> durch eine Hochsprache, eingebettet in einem Code.
Ich weiß jetzt nicht, wie die Kalibierung beim BME680 gemacht wird, aber
es kann durchaus sein, dass die Kalibrierkoeffizienten genau für diesen
Code mit seinen Ganzzahlunperfektionen erzeugt werden. Die Koeffizienten
werden dafür so berechnet, dass der Fehler der mit dem Code erzeugtem
kalibrierten Daten im Sinne von der Summe der Fehlerquadrate minimal
wird. Das kriegst du durch klassische Formeln nur schwer abgebildet.
Steffen H. schrieb:> Wenn dem so ist, dann braucht es ja demnächst keine Datenblätter mehr.> Und Bücher auch nicht. Gibt ja Wikipedia oder Google, was?
Ach das bemängeln wir, dass Bosch die Treiber nicht auf eigenen Servern
zur Verfügung stellt sondern auf Github wo sie von versierten
Entwicklern problemlos in ihre Projekte eingebunden werden
können...verstehe.
Steffen H. schrieb:> Ich sehe die Bibliotheken und Sources auf Git eher als Programmierhilfe> oder Zusatz. Never Ever aber als Datenblatt Ersatz!
Niemand hat behauptet, dass sie ein Datenblatt Ersatz sind.
Steffen H. schrieb:> Denn die Berechnungen können vereinfacht werden, wenn man sich darüber> mal ein wenig Gedanken macht, ob man da wirklich 32bit (Float) oder> sogar 64bit (Double) zum rechnen braucht..
Na dann mal los. Vereinfache die Formeln. Ist ja anscheinend ein Klacks
für dich. Ich tippe aber eher nur auf Geschwätz.
Steffen H. schrieb:> Denn die Berechnungen können vereinfacht werden, wenn man sich darüber> mal ein wenig Gedanken macht, ob man da wirklich 32bit (Float) oder> sogar 64bit (Double) zum rechnen braucht..
Dann guck einfach mal in den Code bevor du meckerst.
Die Gedanken haben sich die Leute bei Bosch Sensortec sogar schon
gemacht und in die Bibliotheken sowohl eine Ganzzahl als auch eine Float
Version gepackt. Du muss nur die dir genehme verwenden (Umschaltung über
BME680_FLOAT_POINT_COMPENSATION)
Wolfgang schrieb:> Dann guck einfach mal in den Code bevor du meckerst.
Ja bist du irre, das wäre doch wieder mit Lesen verbunden. Das geht doch
nicht :D
Gibt es jemanden, der für den ATmega8 eine kleines Programm entwickeln
könnte, um die Temperatur Rohdaten auszulesen und nach diesem Verfahren
die Temperatur zu berechnen:
https://www.bosch-sensortec.com/software-tools/software/bsec/
Mir schwebt ein BME680 Kalkulator / Rechner vor den Augen, bestimmte
Werte von Registerinhalten eingeben und Temperaturergebnis erhalten.
Natrlich mit nachvollziehbaren Rechenweg.
Bernhard S. schrieb:> https://github.com/BoschSensortec/BME680_driver>> Ein Besipsiel in C/C++, sehr komplex, nicht einfach nachvollziehbar
Genau dort liegt die Bibliothek mit den Kalibrierfunktionen für den
BME680 und nennt sich bme680.c (mit zugehörigen Headerfiles).
Die Kalibrierroutine für die Temperatur in der Integer Version heißt -
welche Überraschung - calc_temperature() und liefert einen int16_t-Wert
zurück.
Übrigens, das berechnen der physikalischen Größen ist kein Hexenwerk,
noch nicht mal Mathematik, sonder einfaches Rechnen Grundschule 4 oder
5. Klasse.
Bernhard S. schrieb:> Übrigens, das berechnen der physikalischen Größen ist kein Hexenwerk, ...
Das ändert aber nichts daran, dass du die internen
Kalibrierkoeffizienten geordnet auslesen und mit der richtigen
Skalierung in die Rechnung einbringen musst, falls du nicht alles selber
machen willst (inklusive der Kalibriermessungen).
Bernhard S. schrieb:> Gibt es jemanden, der für den ATmega8 eine kleines Programm entwickeln> könnte, um die Temperatur Rohdaten auszulesen und nach diesem Verfahren> die Temperatur zu berechnen:>> https://www.bosch-sensortec.com/software-tools/software/bsec/
Naja, kommt darauf an, was du unter "klein" verstehst. Angesichts
dessen, was Bosch hier als Codesize für einen AVR8 angibt, wirst du den
Funktionsumfang des Treibers ganz erheblich ausdünnen müssen, um die
Sache überhaupt in einem Mega8 unterzubringen. Das ist natürlich sehr
gut möglich, wenn dich von dem ganzen Kram, den das Teil liefern kann,
eh' nur die Temperatur interessiert.
Allerdings: Wenn das so ist, warum dann zum Teufel ein BME680? Das
ergibt doch keinerlei Sinn.
Andererseits: Warum muss es den unbedingt ein Mega8 sein? In einen
Mega1284P/644P/644 paßt der gesamte Schotter zum BME680 völlig
problemlos und du hast immer noch weit mehr Speicher über, als der Mega8
überhaupt insgesamt hat.
> Mir schwebt ein BME680 Kalkulator / Rechner vor den Augen, bestimmte> Werte von Registerinhalten eingeben und Temperaturergebnis erhalten.
Das geht nicht. Damit die Rechnung irgendeinen Sinn ergibt, brauchst du
die Kalibrierungsdaten, zumindest fünf Bytes davon. Und die sind für
jedes einzelne Exemplar anders, genau deswegen werden sie für jeden
einzelnen Chip relativ aufwendig ermittelt und in den Chip
reingeschrieben.
> Natrlich mit nachvollziehbaren Rechenweg.
Der Rechenweg der Temperaturberechnung ist doch trivial. Da ist absolut
nichts drinne, was über die vier Grundrechenarten hinausgeht. Lass' in
dem C-Code das Typecasting-Geraffel weg, ersetze die Verschiebungen
durch Multiplikationen bzw. Divisionen mit bzw. durch Potenzen von 2,
vereinfache das nach den mathematischen Gesetzen, die du in der
Grundschule gelernt hast, und du erhältst einen Text, der schon ziemlich
mathematisch und ziemlich trivial aussieht:
var1 = temp_adc / 8 - dev->calib.par_t1 * 2
var2 = (var1 * dev->calib.par_t2) / 2048
var3 = (var1 * var1) / 16384
var3 = (var3 * dev->calib.par_t3) / 1024
var3 = var3 + var2
calc_temp = (var3 * 5 + 128) / 256;
Es bleiben als einzige "Fremdkörper" die Verweise auf den Messwert und
die drei Kalibrierungswerte. Das ist halt der Kram, den du aus dem Chip
lesen musst. Da die Kalibrierungswerte sich nicht zur Laufzeit ändern,
liest man die halt nur einmal.
Was bleibt, um das in Asm optimal umzusetzen, ist die weitere Zerteilung
in elementare Operationen und die Analyse der für die einzelnen Schritte
benötigten Bitbreiten.
c-hater schrieb:> Lass' in dem C-Code das Typecasting-Geraffel weg, ersetze die> Verschiebungen durch Multiplikationen bzw. Divisionen mit bzw.> durch Potenzen von 2
Ausgerechnet eine Schiebeoperation ist doch in Assembler eine der
einfachsten Übungen. Keiner - außer dir vielleicht - wird auf die Idee
kommen, die Schieberei aufzugeben und statt dessen eine komplette
Multiplikation bzw. Division anzuschmeißen.
c-hater schrieb:> Es bleiben als einzige "Fremdkörper" die Verweise auf den Messwert und> die drei Kalibrierungswerte.
Und genau das ist das Problem, in welchen Registern sind diese
Kalibrierwerte versteckt, vermultich in denen, welche nicht im
Datenblatt erwähnt werden.
89h to A1h for calibration data 1 to 24
E1h to F0h for calibration data 25 to 40
> Der Rechenweg der Temperaturberechnung ist doch trivial.> var1 = temp_adc / 8 - dev->calib.par_t1 * 2> var2 = (var1 * dev->calib.par_t2) / 2048> var3 = (var1 * var1) / 16384> var3 = (var3 * dev->calib.par_t3) / 1024> var3 = var3 + var2> calc_temp = (var3 * 5 + 128) / 256;
das mag sein, aber in welchem Register befindet sich par_t1, par_t2,
par_t3
>Das geht nicht. Damit die Rechnung irgendeinen Sinn ergibt, brauchst du>die Kalibrierungsdaten, zumindest fünf Bytes davon.
In dieser "Formel" finde ich nur 3 >grübel<
>> Mir schwebt ein BME680 Kalkulator / Rechner vor den Augen, bestimmte>> Werte von Registerinhalten eingeben und Temperaturergebnis erhalten.>> Das geht nicht. Damit die Rechnung irgendeinen Sinn ergibt, brauchst du> die Kalibrierungsdaten, zumindest fünf Bytes davon.
Die Kalibrierungsdaten lassen sich wunderschön, sowie die Rohdaten aus
dem Sensor auslesen. Diese schwungvoll in den Excel Calculator
einpflegen...fertsch
> Warum muss es den unbedingt ein Mega8 sein?
Ein Tiny85 darf es natürlich auch sein, es gibt hier Experten, z.B.
Steffen, die würden das auch schaffen^^
Derzeit ist der ATmega8 nur zu 51% belegt, inc. OLED128x64-Treiber
SSD1306, ADC, Uhr und anderen Routinen die kein Mensch braucht,
allerdings in Assembler mit viel Optimierungspotential.... da passt noch
viel rein.
PS: Hab vorhin Bosch per e-mail kontaktiert, bekam auch sofort eine
Antwort, ich bin jetzt noch extrem maximal begeistert.
https://community.bosch-sensortec.com/t5/forums/searchpage/tab/message?filter=location&q=BME680&location=category:bst_community&collapse_discussion=true
Bin aber in der Community nicht richtig fündig geworden, oder ich habe
etwas übersehen.
Wolfgang schrieb:> Ausgerechnet eine Schiebeoperation ist doch in Assembler eine der> einfachsten Übungen.
Natürlich. Er wollte es doch aber "mathematisch" haben.
> Keiner - außer dir vielleicht - wird auf die Idee> kommen, die Schieberei aufzugeben und statt dessen eine komplette> Multiplikation bzw. Division anzuschmeißen.
Ha, das wiederum ist falsch. Wenn du dir die Aufdröselung anschaust,
wirst du erkennen, dass da schon einiges an Optimierungspotential allein
durch die streng mathematische Vereinfachung erkennbar wurde...
Nein, Mathematik ist nicht sinnlos, auch (und gerade) nicht, wenn man in
Assembler programmiert...
Nur die C-only C&P-ler (finsteres, abartig minderwertiges Volk) haben
sowas nicht drauf...
> Und genau das ist das Problem, in welchen Registern> sind diese Kalibrierwerte versteckt
Vielleicht verstehe ich das nicht so ganz, aber siehe Anhang.
> In dieser "Formel" finde ich nur 3 >grübel<
Da stehen doch 2*2+1 Bytes, oder?
Bernhard S. schrieb:> das mag sein, aber in welchem Register befindet sich par_t1, par_t2,> par_t3
Das steht in dem C-Quelltext. Erstaunlicherweise genau in der Funktion,
wo man es vermuten könnte: get_calib_data()...
>>Das geht nicht. Damit die Rechnung irgendeinen Sinn ergibt, brauchst du>>die Kalibrierungsdaten, zumindest fünf Bytes davon.>> In dieser "Formel" finde ich nur 3 >grübel<
Drei Werte, zwei davon sind 16Bit breit, einer 8. Macht zusammen wieviel
Bytes, du Nase?
S. Landolt schrieb:>> Und genau das ist das Problem, in welchen Registern>> sind diese Kalibrierwerte versteckt> Vielleicht verstehe ich das nicht so ganz, aber siehe Anhang.
Super!!!! Die Lösung . 1000 Dank.
Wo finde ich diese Version, ich kann sie nicht finden?
BST-BME680-DS001-03 Revision_13_072019
par_t1 E9h EA
par_t2 8Ah 8bh
par_t3 8ch
temp_adc 24h 23h 22h
ich arbeite mit einer veralteten Version "BST-BME680-DS001-00" (2017)
c-hater schrieb:>> In dieser "Formel" finde ich nur 3 >grübel<> Drei Werte, zwei davon sind 16Bit breit, einer 8. Macht zusammen wieviel> Bytes, du Nase?
Hey Du Dampfnase, in Mathematik war ich immer gut, nur nicht im
Kopfrechen, sorry.
Diesen Beitrag finde ich auch sehr interesant:
Beitrag "BME680 etwas ATMega-freundlicher auslesen"
Bernhard S. schrieb:> Und genau das ist das Problem, in welchen Registern sind diese> Kalibrierwerte versteckt, vermultich in denen, welche nicht im> Datenblatt erwähnt werden.
In get_calib_data() werden die ganzen Calibrierwerte erstmal durch
bme680_get_regs() in coeff_array[] reingelesen (ab Zeile 728 in
bme680.c) und anschließen in dev->calib (Typ bme680_calib_data)
einsortiert (z.B. ab Zeile 735 für die Temperatur). Die Konstanten, die
die Register, die Länge der Bereiche und die Position im coeff_array[]
angeben, stehen in bme680_defs.h
Guck dir doch endlich mal den Code an.
S. Landolt schrieb:>> Wo finde ich diese Version, ich kann sie nicht finden?> Schlag' nach bei - nein, nicht Shakespeare, sondern - Reichelt.grins
Danke, bei reichelt fand ich die korrekte Version.
Wolfgang schrieb:> Guck dir doch endlich mal den Code an.
Ich denke, das wird momentan nicht erforderlich sein, trotzdem Danke für
den Hinweis.
Diese Register müssten theoretisch verwendet werden:
E9h EA 8Ah 8bh 8ch 24h 23h 22h
PS: ich könnte mich jetzt noch Ohrfeigen, viele Stunden vergeutet und
Eure wertvolle Lebenszeit beansprucht, nur weil ich nicht das aktuelle
Datenblatt verwendet hatte :-(
> ich könnte mich jetzt noch Ohrfeigen
Darf ich auch mal?
Aber Spaß beiseite, ob das bei Reichelt
> das aktuelle Datenblatt
ist, weiß ich nicht, es war schlicht das Erste, das ich in die Finger
bekam.
Bernhard S. schrieb:> Diesen Beitrag finde ich auch sehr interesant:> Beitrag "BME680 etwas ATMega-freundlicher auslesen"
Du glaubst, wir erkennen kein Sockenpuppen, nur weil du sie tanzen läßt?
Mein Gott, sogar meine KI hat sofort 99,8% Wahrscheinlichkeit geliefert.
Und die ist immer noch weit blöder, als ich sie gern hätte...
S. Landolt schrieb:>> ich könnte mich jetzt noch Ohrfeigen> Darf ich auch mal?
ja, kostet aber extra^^
S. Landolt schrieb:> Aber Spaß beiseite, ob das bei Reichelt>> das aktuelle Datenblatt> ist, weiß ich nicht, es war schlicht das Erste, das ich in die Finger> bekam.
Vermutlich hatte ich mein veraltetes von:
https://www.adafruit.com/
Bernhard S. schrieb:> Nun mögen die Berechnugsspiele beginnen :)
Fair wäre, wenn du deine eigene Lösung vorgelegt hättest. Dann könnte
man die so richtig genüsslich zerfleischen...
c-hater schrieb:>> Nun mögen die Berechnugsspiele beginnen :)>> Fair wäre, wenn du deine eigene Lösung vorgelegt hättest.
Um etwas Geduld wird gebeten, Excel ist schon gestartet.
>Dann könnte man die so richtig genüsslich zerfleischen...
Gern, ich bitte darum, ich helfe Euch noch dabei, solange es fair und
konstruktiv ist.
Wenn dann mit der Berechnung noch ein Zuse(Z1) zurecht käme, das wäre
schön.
Bernhard S. schrieb:> Um etwas Geduld wird gebeten, Excel ist schon gestartet.
Excel? WTF? Ich dachte, das Target wäre AVR8 und die Sprache Asm? Ich
sehe nicht, wozu Excel da beitragen könnte...
Wolfgang schrieb:> Die Version von Reichelt ist auch deutlich angestaubt.>> Die aktuelle Version gibt's beim - HERSTELLER
bst-bme680-ds001-06 Super ! Danke für den Tipp :-)
BME680 Rechner / Calculator momentan nur für Temperatur. Einfach die
erforderlichen Registerinhalte auslesen und in die Excel-Tabelle
eintragen.
Es wäre schön, würde mich überaus glücklich machen, wenn jemand einen
Fehler in der Berechnung fände.
Bitte verlangt jetzt kein Kalibrierschein vom digitalen LED-Thermometer,
meine Teetasse stellte ich versehentlich neben den empfindlichen
Temperatursensor TSIC206.
Beitrag "TSIC206 TSIC306 Temperatursensor / Thermometer LCD Assembler ATmega8"c-hater schrieb:>> Mir schwebt ein BME680 Kalkulator / Rechner vor den Augen, bestimmte>> Werte von Registerinhalten eingeben und Temperaturergebnis erhalten.>> Das geht nicht. Damit die Rechnung irgendeinen Sinn ergibt, brauchst du> die Kalibrierungsdaten, zumindest fünf Bytes davon. Und die sind für> jedes einzelne Exemplar anders, genau deswegen werden sie für jeden> einzelnen Chip relativ aufwendig ermittelt und in den Chip> reingeschrieben.
wurde alles mit berücksichtigt
c-hater schrieb:>> Um etwas Geduld wird gebeten, Excel ist schon gestartet.>> Excel? WTF? Ich dachte, das Target wäre AVR8 und die Sprache Asm? Ich> sehe nicht, wozu Excel da beitragen könnte...
Ich dagegen schon, im Datenblatt ist leider keine Beispielrechnung
dabei,
eine kleine Exeltabelle gibt doch etwas Sicherheit, ob die Bitfummelei
in ASM gelungen ist, Du Nase :-)
Die Umsetzung in Assembler ist nicht tragisch, nur etwas zeitaufwändig.
Kommt noch, auch hier bitte ich um etwas Geduld, mit Verlaub.
Bernhard S. schrieb:> Seltsam, im Bereich 0 bis 20°C ist ist der ADC nahezu linear zur> Temperatur
Die nichtlinearen Korrekturen mit var2 sind so klein, dass du sie beim
Plot der Gesamtfunktion nicht siehst. Die Abweichungen von der Geraden
werden besser erfassbar, wenn man nur den Korrekturterm var2/5120.0
gegen die Temperatur darstellst.
Bernhard S. schrieb:
p.s.
> BME680_Calculator_V1.xls
Um dein Excel-WS zu probieren, braucht man noch die
./%08ANALYSE/ATPVBAEN.XLA
Alternativ kann man einfacher eine eingebaute Funktion (HEX2DEC,
HEXINDEZ) benutzen.
Bernhard S. schrieb:> Ein Besipsiel in C/C++, sehr komplex, nicht einfach nachvollziehbar
Eigentlich nicht da da nur Grundlagen C verwendet wird. Und das sollte
heute, 2021, auch jemand können, der High-Level-ASM beherrscht. Sogar
unser C-Hater kann C wie er schon oft hier im Forum bewies.
> Nun mögen die Berechnugsspiele beginnen :)
Was für Spiele? Ist doch alles klar.
Allenfalls eine Frage hätte ich noch: woher, bitte, kommt der Wert
'793b80' in Ihrem 'BME680_Calculator.jpg'?
Bernhard S. schrieb:> Seltsam, im Bereich 0 bis 20°C ist ist der ADC nahezu linear zur> Temperatur, ich hätte ine total verzerrte Kurve erwartet.
So schlimm ist das nicht. Zwischen 0 und 20°C sind das 0.21K durch die
Krümmung deiner Sensorkennlinie (s. Anhang mit Temperaturkoorektur durch
var2-Anteil).
> Allenfalls eine Frage hätte ich noch: woher, bitte, kommt der Wert> '793b80' in Ihrem 'BME680_Calculator.jpg'?
Der ist zusammengebaut aus den Registerinhalten des Wandlungsergebnises
der Temperaturmessung.
S. Landolt schrieb:> Allenfalls eine Frage hätte ich noch: woher, bitte, kommt der Wert> '793b80' in Ihrem 'BME680_Calculator.jpg'?Wolfgang schrieb:> Der ist zusammengebaut aus den Registerinhalten des Wandlungsergebnises> der Temperaturmessung.
Ein kleines Tool "2021-02-19_V2.zip" zeigte mir den Inhalt der
erforderlichen Register an, so wie es Wolfgang beschrieb.
Wolfgang schrieb:> Mit einer Hilfsvariablen xtemp lässt sich der nichtlineare Anteil> vereinfacht darstellen:
Interessant! Wer mit einer vertretbaren Genauigkeit arbeiten möchte,
solange kein Menschenleben in Gefahr ist, könnte mit einer vereinfachten
Formel arbeiten.
Wolfgang schrieb:> Alternativ kann man einfacher eine eingebaute Funktion (HEX2DEC,> HEXINDEZ) benutzen.
Momentan verende ich "Hex2Dec()", hatte aber im Add-In-Manager einiges
akiviert, vermutlich gab's dort mal Probleme.
Bernhard S. schrieb:> Interessant! Wer mit einer vertretbaren Genauigkeit arbeiten möchte,> solange kein Menschenleben in Gefahr ist, könnte mit einer vereinfachten> Formel arbeiten.
Wie groß die Fehler dadurch werden, hängt hauptsächlich vom genutzen
Messbereich ab.
Das war für uns ja nicht ersichtlich, gestern um 21:33 stand im
mittleren Byte noch '10'.
Und auch jetzt bin ich der Meinung, dass es 0x803B7 heißen sollte, der
Wert hat doch nur 20 bit, oder verstehe ich das Datenblatt '5.3.4.2 Temp
data' falsch?
S. Landolt schrieb:> Wert hat doch nur 20 bit, oder
Du hast Recht. Es sind nur 20 Bit. Zu sehen sind die Rohdaten, also die
unveränderten Rohdsten.
In der Berechnung erfolgt dann die Wandlung von 24 auf 20 Bit.
Nun, bei einer Float-Rechnung erwarte ich als Ergebnis eben das, eine
Gleitpunktzahl; hier also, wie es im Datenblatt steht, Grad mit
Nachkommastellen.
Bei einer Integer-Rechnung bekäme man nur ganze Grad, folglich ist es
sinnvoll, Centigrad als Ergebnis zu erhalten; auch wenn das, zugegeben,
so nicht im Datenblatt steht.
Und mir fällt nunmal auf, dass bei Float am Ende durch 5120 dividiert
wird, bei Integer durch 51.2 = 5/256.
PS:
Die erste Frage sollte sein: was wird bei Adafruit hineingesteckt, 20
oder 24 Bit? Sie können dies ganz sicher wesentlich schneller
beantworten als ich.
S. Landolt schrieb:> Nun, bei einer Float-Rechnung erwarte ich als Ergebnis eben das, eine> Gleitpunktzahl; hier also, wie es im Datenblatt steht, Grad mit> Nachkommastellen.
Da kannst du erwarten, was du möchtest und musst evtl. deine eigene
Library schreiben. Der Hersteller hat es nun mal so gemacht, um z.B.
zwischen Int und Float Version keine Bruch zu haben und so ist es nun
mal.
S. Landolt schrieb:> Die erste Frage sollte sein: was wird bei Adafruit hineingesteckt, 20> oder 24 Bit?
Adafruit hat als BME680 Library die von Bosch Sensortec. Und mit der
Rechnung passen die Werte von Bernhard. Der Sensor liefert, je nach
IIR-Filter Einstellung maximal 20 Bit. (DS Kap. 3.3.1Temperature
measurement). Die zusätlichen 4 Bit aus dem einen Register gehören nicht
zum Temperatursensor.
https://github.com/adafruit/Adafruit_BME680/blob/master/bme680.c
> passen die Werte von Bernhard
Da ist mir z.B. unklar, was MSB und was LSB ist. Und eine Raumtemperatur
von 24 °C erscheint mir etwas hoch. Tatsache ist, er steckt 24 Bit rein,
und dividiert am Ende durch 100 (was ich so nirgends im Datenblatt
finde), um auf seine Temperatur zu kommen.
Was mich betrifft, so hätte ich gerne mit den Rohdaten die
Integer-Berechnung aus dem Datenblatt durchgeführt. Ganz simpel und vor
allem unabhängig von 'Adafruit' und schlicht "... for a friendlier user
experience" ignorierend (bei solchen Sätzen bekomme ich ein ungutes
Gefühl, traut Bosch seinem eigenen Datenblatt nicht ganz oder halten sie
die Anwender für wenig fähig?).
PS:
Sie selbst, Wolfgang, haben ja offenbar mit den Datenblattformeln auch
nicht das geringste Problem. Und grundlegende Programmierkenntnisse
sollte Bosch seinen Anwendern doch zutrauen.
S. Landolt schrieb:> Vorschlag: geben Sie uns die Registerinhalte
gern, bei ca.23 Grad Sensortemperatur:
Register / Value
0x22: 0x80 ' ADC
0x23: 0x3b
0x24: 0x79
0xE9: 0x65 ' par_t1
0xEA: 0xc7
0x8A: 0x6a ' par_t2
0x8B: 0x68
0x8C: 0x03 ' par_t3
S. Landolt schrieb:> Das heißt, das 'BME680_Calculator.jpg' von 00:02 ist falsch und> überholt?> Weil dort mit 24 bit gerechnet wird. Und am Ende aus mir unerfindlichem> Grund durch 100 geteilt wird, um ein halbwegs sinnvolles Ergebnis> vorzuweisen.
In der "BME680_Calculator_V1.xls" wird ein 24Bit-Wert eingespeist, das
Ergenis war auch nach meiner Meinung plausibel, könnte aber trotzdem
nicht korrekt sein.
Ich kann's nicht ändern (bzw. besser): mit Ihren Werten, wobei für
par_t1 der plausible, so wie er auch im Calculator steht, genommen wird,
erhalte ich bei der Integer-Berechnung des Datenblattes 0xD7D = 3453.
Keine Ahnung, was das ist, sieht nicht einmal nach c°C aus.
S. Landolt schrieb:> Da ist mir z.B. unklar, was MSB und was LSB ist. Und eine Raumtemperatur> von 24 °C erscheint mir etwas hoch. Tatsache ist, er steckt 24 Bit rein,> und dividiert am Ende durch 100 (was ich so nirgends im Datenblatt> finde), um auf seine Temperatur zu kommen.
Wenn man Bernhards Roh-Werte um die 4 Bit schiebt (-> 0x793b8) und die
Division durch 100 am Ende weg lässt, landet man bei 25.40°C
Das ist dummerweise arg dicht dran. Die Abweichung sollte aber bei
halbwegs sorgfältigem Vergleich mit einem Referenzthermometer noch
auffallen.
Die Integerrechnung kommt mit dem Wert 0x793b8 auf 2540, so dass du
anscheinend Recht hast. Das würde doch gegen Tippfehler im DS sprechen.
Leider habe ich selber keinen BME680 hier.
Bernhard, hast du die Möglichkeit eine genügend genauer
Vergleichsmessung zu machen?
S. Landolt schrieb:> Tatsache ist, er steckt 24 Bit rein
Im C-Quelltext werden von den 24 Bit aus den Registern schon in der
Ausleseroutine 4 Bits weggeworfen. Das ist die Zeile, die Wolfgang
verlinkt hatte.
In der Wandlerroutine werden dann gleich als erstes nochmal 3 Bits
weggeworfen. Effektiv hat also der tatsächlich verarbeitete
Temperaturwert nur noch 17 Bits.
Wolfgang schrieb:> Bernhard, hast du die Möglichkeit eine genügend genauer> Vergleichsmessung zu machen?
Ja, ein kalibriertes Thermometer steht mir zur Verfügung, am kommenden
Freitag könnte ich den Versuch wiederholen und entsprechende
Registerdaten liefern.
Raum-, Außen-, Backofen, Kühlschrank- und Gefrierschrank-Temperatur.
c-hater schrieb:> Welche Genauigkeit kann das liefern?
Ich denke mit +/- 0.5K können wir rechnen.
S. Landolt schrieb:> Vielleicht auch die heute zuletzt angegebenen nochmals sorgfältig> überprüfen.
Ja. Das werde ich tun.
Bernhard S. schrieb:> Ich denke mit +/- 0.5K können wir rechnen.
"denke" ?!? Öhm, das solltest du eigentlich wissen und nicht vermuten.
Wolfgang schrieb:> Leider habe ich selber keinen BME680 hier.
Hast du einen BME/BMP280. Der BME680 ist nur ein BME280 mit zusätzlichem
Luftgütesensor. ;)
Bernhard S. schrieb:> Ich denke mit +/- 0.5K können wir rechnen.
Dir ist schon klar, dass damit nur eine sehr grobe Kontrolle möglich
wäre, oder?
Der BME und die Berechnung haben den Anspruch, deutlich genauere Werte
zu liefern, nämlich ca. auf zwei dezimale Nachkommastellen genaue. Für
nur 0.5K Genauigkeit könnte man die Wandlerroutine bezüglich
Rechenaufwand (und Codegröße) ganz erheblich eindampfen.
Im BMP280 ist der Rechenweg mit einem Beispiel erklärt, vermutlich sind
die Rechenwege BMP280 / BME680 ähnlich, ich konnte es aber noch nicht
prüfen.
c-hater schrieb:>> Ich denke mit +/- 0.5K können wir rechnen.>> Dir ist schon klar, dass damit nur eine sehr grobe Kontrolle möglich> wäre, oder?
Laut Datenblatt des TH-3 sogar nur:
Temperature (Dry Bulb) -20 °C to 60 °C: ±0.8 °C
Ich schau mal auf den Kalibruerschein.
Übrigens, die Berechnungsformel für die Temperatur ist beim BMP280 und
BME680 ziemlich ähnlich, var2 ist etwas anders.
Nur im Datenblatt des BMP280 ist eine vernünftige Beispielrechnung mit
dabei.
Schaltung.png
(32 KB)
Versuchsaufbau.jpg
(170 KB)
