Reading an SHT25 humidity + T sensor. On the Pi, the resolution is bad (~0.5% RH steps). Code (active section):
bus = smbus.SMBus(1)
...
# Send humidity measurement command
bus.write_byte(0x40, 0xF5)
time.sleep(0.5)
data0 = bus.read_byte(0x40)
data1 = bus.read_byte(0x40)
humidity = data0 * 256 + data1
humidity = -6 + ((humidity * 125.0) / 65536.0)
Values (unique): 40.62 40.12 39.63 39.14
... as you can see, sporadic huge gaps.
Using the same sensor on an Arduino, with the equivalent commands:
Wire.beginTransmission(0x40);
Wire.write(0xF5);
Wire.endTransmission();
delay(500);
Wire.requestFrom(Addr, 2);
data[0] = Wire.read();
data[1] = Wire.read();
humidity = (((data[0] * 256.0 + data[1]) * 125.0) / 65536.0) - 6;
I get very smooth RH data with tiny transitions between adjacent values:
35.35 35.32 35.29 35.25 35.22 35.19 35.12 35.09
...and so on. It seems that the Pi is getting bleed-though from the MSB of the answer?? I notice that the MSB seems to jump around more on the Pi, almost as if there's a framing problem?
Note this (MSB, LSB):
94 121
94 120
94 120
93 119
93 119
93 118
93 118
93 117
93 117
93 116
93 116
92 115
92 115
92 115
... as you can see, the LSB (2nd value) goes gracefully down BUT the MSB switches, probably explaining the big gaps. This does not happen with the Arduino code. The LSB has to go all the way down to near zero before the MSB decrements.
I have specified an i2c speed of 100 kbaud. Curiously, if I ask:
sudo cat /sys/module/i2c_bcm2708/parameters/baudrate
...the answer is zero. wut.
I would be most grateful for any suggestions on what I'm doing wrong. Thanks in advance!
EDIT:
Tried using the read_word variant but it has to send a command number, which confuses the SHT25.
Have now switched to using the SHT31, and communicated with it successfully using
bus.write_i2c_block_data(0x44, 0x2C, [0x06])
time.sleep(0.02)
# Temp MSB, Temp LSB, Temp CRC, Humidity MSB, Humidity LSB, Humidity CRC
data = bus.read_i2c_block_data(0x44, 0x00, 6)
etc.
HT to ericksonp for the code! The SHT25 is just a bit too "odd" in its i2c implementation to work easily with the smbus library...
