I'm testing a batch of BME280 modules, ones that look exactly like these on the first image (http://www.kandrsmith.org/RJS/Misc/Hygrometers/calib_many.html) (bottom row, rightmost one). This is a great test BTW, and shows that the BME280 is a quite capable chip. This is the chip used on the WeatherShield v2.
Now, the problem is, whatever library I use - SparkFun, AdaFruit, finitespace, all on GitHub, latest code - I get 2.5-3°C higher temps and 4-6% lower humidity values compared to anything else I have here right now - LaCrosse T/H room sensor, Meas. Specialsts HTU21D, Sensirion SHT11. Reading on the net reveals that the chip uses some kind of self-heating for humidity measurements. If I ventilate the module a bit using a sheet of cardboard, it helps ofsetting the error, making it clear that self-heating is causing the issue. If I stop ventilation, the temp starts to crawl up again. the 2-3 degrees I see are way off the stated accuracy, making the part useless. Strangely enough, pressure values are within 0.1 millibars of my Davis weather station. No problem there.
The WeatherNode example is a bit better. I see only about a 1.2-1.5°C positive offset. Still too much but a bit better, somehow. I noticed that the most significant difference is that the radio and the ATMega is sleeping between measurements in this sketch (as standard for battery operated nodes). I'm attaching a photo of the arrangement. It shows that the module is about 2 cm from the Moteino so direct heating should not be an issue...
Any help is greatly appreciated. I planned to make a series of weather receivers based on the chip but it looks like I'll need to look for other, discrete solutions instead of this integrated wonder.
The BME280 part you are using has an onboard 3.3V regulator. In your picture, you are feeding it 3.3 which leads to a lower operating voltage for the sensor. This may be causing your problem. I would connect the BME280 voltage input to the Vin for the Moteino.
Hmm, thanks for the hint. The breakout module is advertised having 1.8-5V Vin range. I've found a schematic (http://www.winddeal.net/image/024/22222.jpg) for an identically looking module. This suggests a 3.3V LDO, not very surprisingly. It also seems to have a level converter so I could use it with a 5V uC. Could powering an LDO with insufficient voltage (in this case Vin = Vout) cause excessive heat generation? In any case I'll try powering the module using 5V tomorrow.
Using the 5V Vin as power supply makes no difference. I've put a breakout board on a breadboard, about 5-6 cm from the Moteino. It's showing 1°C higher than the other sensors that are in agreement. Still too much. RH is around 3% less, it's within the specs, though according to tests I've mentioned earlier it should be more accurate. Still clueless. I might try to get boards without the regulator so see if it causes the problems.
@kobuki,
From p.10 of the v1.0 2014-11-12 BME280 module datasheet:
QuoteTemperature measured by the internal temperature sensor. This temperature value depends on the PCB temperature, sensor element self-heating and ambient temperature and is typically above ambient temperature.
IMHO, the temperature measure is of the internals is specifically to correct the reading for RH temperature, not targeted at accurate monitoring the passing air temperature. This is consistent with p.3 (my emphasis):
QuoteIts output is used for temperature compensation of the pressure and humidity sensors and can also be used for estimation of the ambient temperature
That's all fine, and I've read it too, but the temperature accuracy is specified as +-0.5°C. The underlying technology is important but totally indifferent. Felix wouldn't have chosen this chip for his WeatherMote either with such an abysmal accuracy. The mentioned tests also confirm this accuracy. I only need the specified accuracy, not more. The statement you quoted only says the expected reported temperatures are above the actual temperature, not how much above.
All in all, the module is either faulty or there's some unknown trick.
@kobuki,Quotethe temperature accuracy is specified as +-0.5°C (of the substrate)
There is clearly some self-heating going on which pushes the substrate above the ambient you are looking for.
What is set for the internal sampling rate (0xF5 register)?
Accuracy spec is of the temperature sensing functionality of the part, not of a component of the part. No dataseet works like that (without specifying that it's not the part's spec but some component substrate or anything else). That would be an obvious scam. I could repeat myself here, tests show the accuracy specified in the datasheet is indeed attainable.
However, good point with the sampling rate. I'll check it, no idea of its settings.
EDIT: After checking, I remember trying 0.5 ms and 20 ms (in the datasheet: 5.4.6 Register 0xF5 "config"). I'll try more extreme values, like 1000 ms. It's the BME280.settings.tStandby setting.
Setting the mentioned tStandby to 1000 ms didn't help... I'm suspecting the board's LDO. It's always powered and might be able generate enough heat to offset the readings. Though I can be entirely mistaken. I only have this kind of breakout board right now with this chip. I might get boards without LDO later and see if they're better.
high tStandby is to reduce noise, you have offset, that won't help it
did you try to power down, wait long period, power up, do reading and power off and again power on, do reading? if you suspect the regulator, that will eliminate it
I'm putting it to sleep after measurements. Yes, I've thought of powering it from an IO pin for the duration of the measurements only. That's not a viable option now and need a lot of testing but I might implement it over time. I would be happier if I didn't have to resort to these tricks, though. None of the other T/H chips I use exhibit this behavior.