I have BMP180 connected to my RPi, I can read calibration data from it, but when I try to get pressure / temperature data -- I get 80 00 for temp and 80 00 00 for pressure (mean -- 'just-after-reboot value') the communication log (reading data part) looks like:

device <--   f4
delay for (asked 50us) 0s 0ms 57us
device <--   2e
delay for (asked 50us) 0s 0ms 56us
delay (asked 5 ms) for 0s 5ms 139us
device [f6] ->  80 00
device <--   f4
delay for (asked 50us) 0s 0ms 56us
device <--   b4
delay for (asked 50us) 0s 0ms 393us
delay (asked 14 ms) for 0s 14ms 149us
device [f6] ->  80 00 00
bcm085: t=51.1 p=104462
chipid: 85 version: 2 Calibration data:  ac1=0198 ac2=ffb8 ac3=c7d1 ac4=7fe5 ac5=7ff5 ac6=5a71  b1=182e  b2=0004  mb=8000  mc=ddf9  md=0b34 Raw data:  rt=8000 rp=020000

50 µs delays after each read/write operations can be dropped from sequence with same result. also, increasing wait times from 5 ms to any -- won't help.

Communication code:

#define BMP180_READ_ADDRESS 0x77
#define BMP180_WRITE_ADDRESS 0x77

#define BMP085_REG_CHIPID       0xD0
#define BMP085_REG_VERSION      0xD1
#define BMP085_CMD_CONTROL      0xf4
#define BMP085_REG_TEMPDATA     0xf6
#define BMP085_REG_PRESDATA     0xf6
#define BMP085_CMD_READTEMP     0x2e
#define BMP085_CMD_READPRES     0x34
#define BMP085_CMD_SOFTRESET    0xE0

// get raw temperature
i2c_reg_set8(BMP085_CMD_CONTROL, BMP085_CMD_READTEMP);


char tempReadBuf[2];
i2c_read_reg(BMP085_REG_TEMPDATA, tempReadBuf, sizeof(tempReadBuf));
tempRawData = (int)tempReadBuf[0] << 8 | (int)tempReadBuf[1];

// get raw pressure
i2c_reg_set8(BMP085_CMD_CONTROL, BMP085_CMD_READPRES + (oversampling << 6));
rpi_delay(2 + (3 << oversampling));

char presReadBuf[3];
i2c_read_reg(BMP085_REG_PRESDATA, presReadBuf, sizeof(presReadBuf));
presRawData = (int)presReadBuf[0] << 16 | (int)presReadBuf[1] << 8 | (int)presReadBuf[2];

presRawData >>= (8-oversampling);

I use libbcm2835 library for access device, without any other libs like wiringPi or smbus. i2c_* and rpi_delay functions are wrappers over libbcm2835 and they do work with other devices.

Can somebody help me please with finding an issue?

Update: more detailed code on pastebin:

  • Given that you say the library and (presumably) your code works with other devices one has to assume you are not configuring the bmp085 correctly. Alternatively your wiring might be incorrect.
    – joan
    Commented Apr 9, 2015 at 7:38
  • i do get chip id, version, and non-null calibration coefficients from bmp180, so wiring should be ok. ths is not 085, this is 180, but from what i see in internet -- they are equial in terms of communication.
    – dima_weber
    Commented Apr 9, 2015 at 8:19
  • That sort of supports that the wiring is correct. That only leaves the configuration or perhaps the underlying I2C command is wrong for the chip. You haven't given a link to the specs of the chip or (I guess) the break-out module you are using which incorporates the chip.
    – joan
    Commented Apr 9, 2015 at 9:33
  • ae-bst.resource.bosch.com/media/products/dokumente/bmp180/… here is datasheet for bmp180
    – dima_weber
    Commented Apr 9, 2015 at 11:12
  • I don't have time to look through your code, but I do have some working C++ for the BMP085 using the generic smbus (<linux/i2c-dev.h>) interface. I'm gonna disagree a bit w/ joan in that I think just because you have a methodology for talking with one I2C device does not mean it will work with all I2C devices.
    – goldilocks
    Commented Apr 9, 2015 at 13:33

2 Answers 2


the borsch documentation for the chip is available at: http://ae-bst.resource.bosch.com/media/products/dokumente/bmp180/BST-BMP180-DS000-12.pdf

the chip documentation does not agree with the posted code.

Please read/understand the documentation, then design the code.

Amongst other things, the three byte pressure is not sequential bytes and the way to tell if a conversion is complete is to read the control register and look at bit 0x40, which will be 0 when the conversion is complete. The oversampling count is set by bits 0xC0 in the control register. and several other problems with the posted code.

If any more misunderstandings arise about the documentation or how to write the code, then update the question

register 0xD1 is not defined, so no version available.

Please read the documentation.

  • suggest reading the ID register as a method of testing if the communication is correctly implemented. Commented Apr 9, 2015 at 20:41
  • per the documentation, the device address is 0xEE or 0xEF depending on if a read or a write operation is to be performed, not 0x77 Commented Apr 9, 2015 at 20:56
  • reading 0x40 bit for conversation isn't work and if you look into pds block-scheme for algorithm you will see that they use delays there. Oversampling is set by 0xC0 bits, agree, oss << 6 do exactly this. device do not reply on 0xEE / 0xEF codes at all and give at least coefficients on 0x77, i2c detect shows it as 0x77 (actually, 0x77 is a max avail i2c code), so regarding code i see it as lib itself add last bit 0/1 depending is it read or write (and you get exactly 0xEE / 0XEF from 0x77 << 1 | 0/1)
    – dima_weber
    Commented Apr 10, 2015 at 13:49

When I had a similar problem, I found that writing the commands in two separate 1-byte write(2) calls leads to this: I was able to read calibration data, but UT and UP reads resulted in 0x8000 and 0x800000 respectively. After I changed my write(2) of Start Measurement commands from two 1-byte writes to a single 2-byte write, I started to get sensible output.

If this still didn't help, I suggest you to compare the result of running strace over simpletest.py from this GitHub repo with the strace results for your program. This was how I guessed to try 2-byte writes which helped me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.