BMP085 Barometric Pressure Sensor

[mdanh2002]

Hi,

Did anyone attempt this sensor module before? The interface is I2C. I have 2 of this module at home now, purchased from different eBay sellers, and have tried both. Unfortunately, none seems to give me valid measurements.

The problem seems to be in the calibration data AC4/AC5/AC6. The values are listed below.

For first sensor

ac1 -118
ac2 -986
ac3 -14302
ac4 65528
ac5 65473
ac6 65453
b1 5498
b2 50
mb -32768
mc -67
md -128

For second sensor

ac1 -71
ac2 -50
ac3 -14528
ac4 65446
ac5 65488
ac6 16146
b1 5498
b2 56
mb -32768
mc -67
md -128

Although some of these values are similar or the same as the datasheet, values for AC4, AC5 and AC6 seems too big. The uncalibrated temperature (UT) value is 25180 for sensor 1, from which the temperate is calculated to be -50 deg C, which is incorrect.

I am using bit-bang I2C on a PIC24F.

Any ideas why, or do I simply have faulty sensors?

Hope somebody will reply me, my previous thread on interfacing CSTN LCD goes unanswered

 

[DirtyLude]

I would be surprised if you received a faulty sensor. It would be extremely unlikely that you would find 2.
I'm way to lazy to set one of mine up just to check the calibration values, but I suspect if you are getting faulty data it may have something to do with your I2C routine.

In case it helps you.
https://www.electro-tech-online.com/threads/bmp085-barometric-pressure-sensor.104889/

 

[mdanh2002]

Thanks for your reply. Let me try one more time again with my oscilloscope and see what the real values are. Attempted it yesterday but confused by the I2C SDA/SCL signals after the first few bits, and gave up.

The reason why I suspect the sensor is faulty is because the same I2C routine has been used for various other I2C peripherals. including 24C64, DS1307 and DS1621 and it works well. When I first used the code with this sensor, the values all read invalid but consistent values. Using an oscilloscope, I figure out that the bit-bang I2C clock on a PIC24F at 32MHz is too fast for the sensor to catch up. By adding a delay I reached the current set of values. Most values seems in the same range as the datasheet sample figures, except for AC4 and AC5 which is almost the maximum size of a 16-bit unsigned integer (datasheet and other online sources show these figures to be in the range of 20000-30000, despite the datasheet saying that these numbers are of typed unsigned short 0-65535). I try adding delay here and then in the bit bang routines but could not get valid values.

How likely do you think it is for a buggy I2C routines to retrieve valid data in most cases, yet returning invalid results for only 2 values? This is the part that drives me crazy when dealing with hobbyist uC projects - sometimes I can't simply find the reasons why things just don't work, and attributing it to faulty components doesn't really make sense.

Could it be the calibration data is faulty? Does anyone here have similar values, e.g. 65xxx, for AC4/5?

 

[JimB]

Although I have no experience of the pressure sensor, I have been thinking about the problem at odd time during the day and cant help but think that the incorrect values are something like twice as large as we would expect compared with the example in the Ptx datasheet.

Twice as large sounds like a load of bits shifted one place to the left.
I suspect that your I2C routine is a bit iffy, despite the fact that it works OK with other stuff.

If your scope has digital storage, try capturing a read of the calibration parameters and decode them by hand and see what you get.

JimB

 

[dr pepper]

I tried to interface to one of these a while back, the first one didnt reply and the second (afetr returning the first one back to the ebay supplier) returned values that were all over the place (pic16f88 at 8mc's internal).
There time to mess so I came up with a diffo solution.
I suspected that my code was messed up, unless theres a bad batch out there.
About the same time I tried playing with a dht22 temp/humid sensor, the timings on the 3 I had were wildly different that the datasheet and they got chucked in the scrap box too.

 

[mdanh2002]

Thanks JimB, will try with the oscilloscope again and see what I got.

@dr pepper: I also tried with a DHT11 before. For one day could not get it to work - I get wild values for temperature and humidity. The next day I woke up, look at it on an oscilloscope, add some delay to adjust the rise and fall time from 0 to 1 and vice versa. Only then did everything seem to work.

I also attempted interfacing an ultrasonic sensor I got from ebay before to measure the distance and it works without hassle.

 

[dr pepper]

Well theres a difference between dht11 and dht22, I've used dht11's with success a few times, I wonder if the code in the dht22 isnt fully developed, theres a couple of sites on the net that backup my findings, the datasheet very loosely applies to the dht22, the dht11 on the other hands behaves fairly well.

I'm interested to find out if you get the bmp working properly.

 

[mdanh2002]

After 1 afternoon looking at the I2C signal on my scope, decode it by hand to get the correct calibration values. I fixed the problem. The values read from the sensor are now proper and temperature/pressure makes sense.

The problem is in the following code to read a word via I2C from the sensor:

unsigned short bmp085ReadUShort(char address)
{
char msb, lsb;
unsigned short data;

i2c_start();
i2c_write(BMP085_W); // write 0xEE
i2c_write(address); // write register address

i2c_start();
i2c_write(BMP085_R); // write 0xEF

msb = i2c_rx(1);
lsb = i2c_rx(0);

i2c_stop();

// PROBLEMATIC CODE HERE!
data = msb << 8;
data |= lsb;

return data;
}

When retrieving the high and low byte, I merge them into a word. The above code looks correct, but after the line data |= lsb, the higher byte of data (of type unsigned short) will become 0xFF due to overflow if msb is greater than 0. This makes the code appear to work properly for some small values and return wrong results for big values.

I changed the above 2 lines to

data = msb << 8;
data = data + (unsigned short) lsb;

and everything is now perfect!

 

[JimB]

Sounds good!

JimB

 

[dr pepper]

Unfortunately I program in asm.

So are you saying that the datasheet is incorrect like the dht22?, no wonder I couldnt get it to work

 

[mdanh2002]

Hi Dr pepper,

The datasheet is mostly correct, except for some timing parameters (e.g. delay before trying to read pressure/temperature values) and the sensors are also fine, the problem is due to the merging of 2 bytes into one word in the sample source code provided by the seller. I changed it as above and it works perfectly.

Let me purchase a few DHT22 from eBay and try to see if I can get them working

 

[dr pepper]

Ok then.

You should be able to get the dht22 working others have done it, be prepared to spend a load of time messing about, I wasnt.

 

[Angry Badger]

Hi,

Just begun to toy with this sensor.

Apart from the first one all the returned calibration values have the lower byte = 0xFF. Seems a bit weird.

What do you think, bad I2C code or the values are ok if that's what's returned?

**broken link removed**

[EDIT] Sorted:

Was doing ACKEN = 1 then ACKDT = 0 in master acknowledge routine. Changed it to ACKDT = 0 followed by ACKEN = 1.

**broken link removed**

 

[dr pepper]

That looks more like it.
Did you so it in asm or C?

 

[Angry Badger]

Hi there,

XC8. That's as far as I got with it, busy with other stuff (trying to help other people on forums ). Next week hopefully I'll try to do the actual calcs for pressure / temp and then integrate it into my main I2C learning project that has separate temp and humidity sensors as well as RTC and lcd. All I2C.