MPL115A2: Unstimmigkeiten Datenblatt <=> reale Werte

[Timmo H. (masterfx)]

Ich habe mir mal einen Dead-Bug gelötet und zwar aus dem 
Luftdruck-Sensor MPL115A2.
Ich fand das Teil interessant, da es schön günstig ist (~1,70€).
Die Genauigkeit ist mit 1 kPa angegeben und ein Temperatursensor ist 
auch noch drin. (Datenblatt: 
http://cache.freescale.com/files/sensors/doc/data_sheet/MPL115A2.pdf)

Im Betrieb ist der Dead-Bug natürlich nicht mehr über Kopf aufgelebt, 
sondern richtig rum und oben offen.

Der Temperatursensor wird hauptsächlich zur Temperaturkompensation des 
Drucks verwendet (nach dem Polynom: [ a0 + (b1 + c11*Padc + c12*Tadc) * 
Padc + (b2 + c22*Tadc) * Tadc ] )

Was mich jedoch stutzig gemacht hat ist der Temperaturwert.
Lauf Datenblatt ist der Temperaturwert bei 25°C 472 und -5.35 — 
counts/ºC.

Soweit so gut.
Diese angaben können aber nicht stimmen. Denn bei 25°C habe ich etwa 
einen ADC-Wert von 530.
Die Berechnung über die Formel "Temp = 25 + (tempADC - 472)/-5.35" 
resultiert demnach in einer zu niedrigen Temperatur (10°C weniger). Klar 
wenn ich jetzt
"Temp = 25 + (tempADC - 530)/-5.35 " rechne stimmts wieder einigermaßen, 
aber ob meine empirisch ermittelten "530" jetzt so genau sind... das ist 
mir einfach zu wage. Und das kann ja auch nicht Sinn und Zweck sein

Ich vermute, das wegen dieser Unstimmigkeit ggf. auch mein Luftdruck 
falsch errechnet wird. Denn ich erhalte nach dem Polynom einen Druck von 
~997 hPa,  wobei hier eigentlich laut den anderen Barometern momentan 
1014 hPa herrschen sollte. (12m über NN)

Das Datenblatt ist ja schon in Revision 7, eigentlich sollte das doch 
nicht sein, dass so ein gravierender Fehler nicht auffällt oder?
In den Freescale-Foren findet man darüber auch nichts.

[Timmo H. (masterfx)]

Noch niemand mit dem Ding gearbeitet?

[Timmo H. (masterfx)]

Ok, Freescale hatte da wohl folgende Antwort drauf:

"Anyway, while we output temp on MPL115A, the temp sensor is used to
calibrate and make our Pressure output more accurate, not provide accurate
temperature determination. That was a cost reduction choice. If we provided
a calibrated temperature, then we would add cost to the test procedure. 
The next generation MPL3115A now has calibrated temp output. 
Its production is is end of Q4 this year.

Regarding temperature conversion, the fact is that the 25 deg C is supposed to be set at 472 ADC counts 
on the Tadc output from MPL115A. It is a negative slope, such that its -5.35 ADC counts per a deg C.
I worked out the transfer function to be somewhat like:
 
Temp = (Tadc - 605.75) / -5.35
 
At -40 deg C the output value should be of 819.75 and at 105 deg C the output value should be of 44. 
 
Note that because the value is a 10 bit, it cannot in the real world always be assumed to be a full 
range output. Even a 9 bit number cannot accommodate this range, so its 10. "

Was aber immernoch nicht erklärt warum "Temp = (Tadc - 605.75) / -5.35" 
so ein falsches Ergebnis liefert (sprich 530 anstatt 472 bei 25°C).

[Timmo H. (masterfx)]

Nochmal was du Druck. Ich habe gerade nochmal meinen analogen MPX4115A 
angeschlossen und die Werte verglichen. Der MPX4115A liefert 1014 hPa 
und der MPL115A2 liefert 996 hPa (nach der Kompensation). Der RAW-Wer 
ist 320.

[Michael (Gast)]

@ timmo, damit du keine Selbstgespräche führen musst:
Habe auch ähnliche Probleme mit dem Ding. 970 hPa bei einem Padc 343 und 
Tadc 515. Tatsächlich sollten es 1022 hPa sein. Du bist ja schon 
wesentlich näher dran. Bin mir allerdings nicht sicher, ob ich alle 
Koeffizienten richtig ins Gleitkomma-Format gebracht habe.

[Timmo H. (masterfx)]

Ahh, doch jemand mit dem Ding.
Also ich habe das jetzt folgendermaßen gemacht.
Ich habe den kompensierten Wert nun auf NN umgerechnet. Gut, der ist 
eben ~ 18 hPa unter dem Tatsächlichen.
Jetzt habe ich einfach diesen "Offset" von 18 hPa einfach immer drauf 
gerechnet und das scheint recht gut zu passen.
Zumindest habe ich jetzt bis auf +-1 hPa genau den Wert von der 
Wetterstation in einem Bereich von 995 - 1035 hPa (mehr hat der 
Luftdruck in den letzten Monaten nicht geschwankt). Aber einen größeren 
Bereich muss man ja auch eigentlich nicht abdecken.

[old_school_offline (Gast)]

Hallo zusammen

bin gerade dabei den MPL115A2 und die übermittelten Daten zu verstehen 
...

habe das mal aufgedruselt ... ist das so wie im Bild OK

Gruss Ralf

[Timmo H. (masterfx)]

Mag sein, aber warum machst du das überhaupt? Ohne die Werte durch den 
(vorgegebenen) Kompensationsalgorithmuss zu jagen machen die Werte eh 
keinen Sinn.
Darum bin ich inzwischen zu den nur unwesentlich teureren MPL3115A2 
gewechstelt. Der spuckt einem gleich die kompensierten Werte raus (Druck 
oder Höhe) und man kann den Temperatursensor auch noch zur 
Absolutmessung verwenden. Die Auflösung ist ausreichend (siehe Bild)

[troll (Gast)]

Timmo H. schrieb:
> Die Auflösung ist ausreichend (siehe Bild)

Beeindruckend. Gab es nicht gerade erst einen Thread wo es um präzise 
Höhenmessungen mittels Luftdruck ging?

[old_school_offline (Gast)]

>> Mag sein, aber warum machst du das überhaupt? Ohne die Werte durch den
>> (vorgegebenen) Kompensationsalgorithmuss zu jagen machen die Werte eh
>> keinen Sinn.

weil ich die Werte zum testen erst mal in integer umwandeln will ?!

und irgendwie nicht mit den factional Bits klar komme ???

mir ist schon klar das man die Werte zur Kompensation benötigt ...

Es ist der MPL115A2 verbaut ... und soll es auch bleiben ...

[Timmo H. (masterfx)]

Aso, ja aber dafür nimmt man doch einfach die Appnote AN3785 kopiert den 
Algo daraus.
Da steht dann auch sowas drin wie

Padc = (mpl115a1_regs[0x00] << 8) |mpl115a1_regs[0x01];
Tadc = (mpl115a1_regs[0x02] << 8) |mpl115a1_regs[0x03];

[Klaus (Gast)]

Timmo H. schrieb:
> Der spuckt einem gleich die kompensierten Werte raus (Druck
> oder Höhe) und man kann den Temperatursensor auch noch zur
> Absolutmessung verwenden. Die Auflösung ist ausreichend (siehe Bild)

Sieht beeindruckend aus. Wie wirkt sich das schnelle Öffnen einer Tür 
oder eine Windbö (Schreibtisch und Wind passt wohl nicht) auf den 
Messwert aus. Mir fehlt da jede Vorstellung.

MfG Klaus

[Timmo H. (masterfx)]

Um die Druckänderung die durch das Öffnen einer Tür verursacht wird 
müsste man im "One Shot Mode" so schnell samplen dass es sprichwörtlich 
im Rauschen untergeht.
Der obige Plot war glaub ich über 30s entstanden, dabei mir einem 
ordentlichen Tiefpass drüber.

Eine Absolut-Höhenmessung kann man aber eh nur über einen recht kurzen 
Zeitraum realisieren, da der Luftdrück selbst über einen kürzeren 
Zeitraum relativ stark schwankt (zumindest in dem Messbereich von 
wenigen Pascal, den man ja braucht um die 30cm aufzulösen)

[Ralf G. (old-school)]

>> Aso, ja aber dafür nimmt man doch einfach die Appnote AN3785 kopiert den Algo 
daraus.
>> Da steht dann auch sowas drin wie

Der Sensor ist für meine Hausbus-Steuerung und die habe ich in RQ 
geschrieben ...
da kann ich die Codes aus den Appnote leider nicht übernehmen ...

[Timmo H. (masterfx)]

Ralf G. schrieb:
>>> Aso, ja aber dafür nimmt man doch einfach die Appnote AN3785 kopiert den Algo
> daraus.
>>> Da steht dann auch sowas drin wie
>
> Der Sensor ist für meine Hausbus-Steuerung und die habe ich in RQ
> geschrieben ...
> da kann ich die Codes aus den Appnote leider nicht übernehmen ...
Aber zumindest die Vorgehensweise. Dort ist eben auch um Umsetzung in 
Int etc erklärt. Ich kenne RQ nicht, hab ich bis eben nocht nichtmal 
gehört, aber sowas wie Schieben oder so gibts da doch sicherlich auch?!

[Ralf G. (old-school)]

die Appnote AN3785 werde ich mir noch mal in Ruhe ansehen ... soweit es 
geht dann übernehmen ...

[Ralf G. (old-school)]

So sieht derzeit meine Schaltung aus, kommt in einem IP64 Gehäuse mit 
transparenten Deckel an die Aussenwand (Norden).

[old_school_offline (Gast)]

>> Ich kenne RQ nicht, hab ich bis eben nocht nichtmal gehört

RQ = RapidQ ist ein Basic-Compiler und dabei noch schneller als C ...
wird aber leider seit 2000 nicht mehr weiter entwickelt ...

siehe auch WIKI

http://en.wikipedia.org/wiki/RapidQ