bmp180 reading of values

[A.Harrenberg]

Hi,

What type is the return value of your getter? What is the channel definition looking like? Do you use BMP180 with oversampling?

I use "FOUR_BYTES" and "TWO_DECIMALS" for the channel (in kpa -> results in one decimal when converting to mbar), the getter is defined as "long", but I don't think it is a problem in the "transmission" via Zwave, as I also see this discrete changes in the serial debug output when I diretly print the result from readPressure(). The default from the library seems to be using oversampling, I am not requesting any mode, so yes, oversampling should be used...

I will try to read out some raw values and do some external calculation to see whether there is a problem in the way the formulas are implemented in the library.

Do you have experience with the sensor and can tell if these discrete steps are normal? Then I could stop all my investigations...

Regards,
Andreas.

[ftrueck]

Seems the sensor resolution is not high enough to provide more granularity. Maybe the calculation is too much rounding through the casts. Currently I have no BMP180 for testing here. I have only a BMP 280 and currently I'm porting a library for Z-UNO. I can test when I'm finished with porting.

[michap]

Just have tested BMP180 with Arduino - it is working as expected:

[edit/deleted]: forget about my old comment - will add later a "right" one...

Michael

[michap]

It seems the Library for Z-Uno have a problem.
Have used the ZUNO_BMP180 lib and bmp.readPressure() value.

Simulating different pressure at sensor at Z-Uno
(pressure was increased slowly):

Code: Select all

Pressure = 100660 pa
Pressure = 101418 pa
Pressure = 102176 pa
Pressure = 102178 pa
Pressure = 102178 pa
Pressure = 102935 pa
Pressure = 102936 pa
Pressure = 101418 pa
Pressure = 100660 pa

Same at Arduino:

Code: Select all

Pressure = 100847 Pa
Pressure = 101049 Pa
Pressure = 101171 Pa
Pressure = 101177 Pa
Pressure = 101292 Pa
Pressure = 101334 Pa
Pressure = 101367 Pa
Pressure = 101460 Pa
Pressure = 101471 Pa
Pressure = 101487 Pa
Pressure = 101490 Pa
Pressure = 101449 Pa
Pressure = 101467 Pa
Pressure = 100806 Pa

We can see that the steps at Arduino are much smaller - it can be reproduced.
For Z-Uno minimum about 758 units.

My first results (previous deleted post) didn't show real pressure difference, but measured value tolerance error.
That's why I thought all is ok

Best regards
Michael

PS: already reported to developers

[A.Harrenberg]

Hi Michap,

thanks for your investigation. It shows what I am experiencing and it also show that there seems to be an issue with loosing resolution here by applying the calculation steps in a not ideal sequence or by using the too much rounding through the casts.

To whom have you reported it? The adafruit team? Can you keep me/us updated on the feedback?

Thanks,
Andreas.

[michap]

To whom have you reported it? The adafruit team?

Have reporteted to Z-Uno developers, the original Adafruit lib is working fine (second values)

Michael

[ftrueck]

you could try to use the adafruit code in the ZUNO Library.
It should not be so hard to copy/paste it into the library.

I've recently seen a library which uses a function called computeB5(). I think this one will provide better values but I am not sure because I could not test it with my BMP280.

[p0lyg0n1]

First of all we can read "Raw Data" (readRawPressure method). We can check if "true" value changes in another way then raw data.

Try to check it myself.

[A.Harrenberg]

Hi,
I am letting it run now with readRawPressure and readPressure() in 5 seconds interval and will try to make an analysis later this night. At the moment I can see that the raw-value has some slight variance and the calculated pressure also, in the range of plus/minus 0.02 hpa.

I am loosing the last digit here when I send that data as kpa using the ZWave protocoll, but what I have seen from these measurements is that the signal will have this slight variations, but then a much larger step of approx. 4 hpa is applied.

I will let it run now for a while and see what I get.

Thanks,
Andreas.

[A.Harrenberg]

Hi,

ok, the rawdata shows the same effect... But the attachement quota is reached, I can't post the pictures...
I have put the pictures for rawPressure / Pressure, rawTemperature/TemperatureC10 as well as the serial debug code I used on google:

Pressure: https://drive.google.com/open?id=0B-Qev ... 0ZDQWZhZWs
Temprature: https://drive.google.com/open?id=0B-Qev ... npsZ2QxMDQ
Data: https://drive.google.com/open?id=0B-Qev ... URiTlBJT3c

The calibration factors of my BMP180 are:
ac1 8703
ac2 -1025
ac3 -14337
ac4 -30721
ac5 25855
ac6 18687
b1 6655
b2 255
mb -32513
mc -11777
md 2559

oversampling should be at "3", as this is the default. I tried to make the calculation from the raw data to the temperature and pressure in excel. This works for the example that is given in the BMP180 specification. The result is very close to the value from example given the fact that I use some sort of "float" calculation in excel rather than fixed point.

But with my calibration factors and my rawdata that fails... I get negative values around e.g. -110018.
In comparison to the example values, my ac4 value is negative and in the specification ac4 is defined as unsigned short... When i change my negative value of -30721 to the 2complent value of 34815 I get the same results as the library. The definition of ac4 is uint16_t, so that is ok, it seems that the serial.print is expecting signed values...

But nevertheless, the problem is still there. The rawdata for pressure in my recording is only changing in a few variations. I sorted all values and compared each value with all the other values, the differences that occure in my data are:

0 0000 00000000 00000000
1 0001 00000000 00000001
2 0002 00000000 00000010
3 0003 00000000 00000011
4 0004 00000000 00000100
5 0005 00000000 00000101
6 0006 00000000 00000110
7 0007 00000000 00000111
2041 07F9 00000111 11111001
2042 07FA 00000111 11111010
2043 07FB 00000111 11111011
2044 07FC 00000111 11111100
2045 07FD 00000111 11111101
2046 07FE 00000111 11111110
2047 07FF 00000111 11111111
2048 0800 00001000 00000000
2049 0801 00001000 00000001
2050 0802 00001000 00000010
2051 0803 00001000 00000011
2052 0804 00001000 00000100
2053 0805 00001000 00000101
2054 0806 00001000 00000110
2055 0807 00001000 00000111

so it seems that there are changes from 0 up to 7 and then there is a step to 2041. At the moment I can't detect the reason behind this, but the problem exist at the raw reading level...

I will try to swith to ultralowpower mode without oversampling and see if this has some influence.

Regards,
Andreas.