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.