View previous topic :: View next topic 
Author 
Message 
Mrshilov
Joined: 24 Jan 2009 Posts: 314 Location: Russia

Posted: Tue Dec 15, 2015 1:41 pm Post subject: BME280 sensor 


BME280 is a combined digital humidity, pressure and temperature sensor. Attached library for I2C mode, but it can be easy adapted for SPI.


Back to top 


aphawk
Joined: 23 Jan 2010 Posts: 152 Location: Brazil

Posted: Wed Dec 16, 2015 1:29 am Post subject: 


Mrshilov,
Thanks for the Lib. Is very nice have all this sensors in one unique module.
Paulo 

Back to top 


albertsm
Joined: 09 Apr 2004 Posts: 4958 Location: Holland

Posted: Thu Dec 17, 2015 10:22 am Post subject: 


Hello Mrshilov,
thanks for sharing this project. I always like the fact that you include a PDF and a sample.
This looks like a super sensor. The LCD looks sharp and clear too. _________________ Mark 

Back to top 


OFamily
Joined: 23 May 2010 Posts: 169 Location: Japan

Posted: Thu Mar 16, 2017 11:15 am Post subject: 


Hi Mrshilov,
The procedure for converting formulas from your C language is wonderful!
please tell me.
Conversion of humidity coefficient is not wrong?
Register 0xE5 is 0xE5 [3: 0] and 0xE5 [7: 4].
Therefore, I think that there is no Temp [8].
Best regards
Code:  Temp(1) = &HA1 ' Read Humidity calibration
I2creceive Slave , Temp(1) , 1 , 1
H1 = Temp(1)
Temp(1) = &HE1
I2creceive Slave , Temp(1) , 1 , 8
H2 = Makeint(temp(1) , Temp(2))
H3 = Temp(3) : H4 = Temp(4) : Shift H4 , Left , 4
Temp(5) = Temp(5) And &H0F : H4 = H4 + Temp(5)
H5 = Temp(6) : Shift H5 , Left , 4
Temp(7) = Temp(7) And &H0F : H5 = H5 + Temp(7)
H6 = Temp(8)
Return 


Back to top 


Mrshilov
Joined: 24 Jan 2009 Posts: 314 Location: Russia

Posted: Thu Mar 16, 2017 1:40 pm Post subject: 


Yes, you are right  it's wrong. Also I find another error in hum procedure. In attachment corrected version & proteus model.


Back to top 


OFamily
Joined: 23 May 2010 Posts: 169 Location: Japan

Posted: Fri Mar 17, 2017 11:35 am Post subject: 


Thanks for the fix!
There was a difference of 0.2% humidity with my routine, but it was consistent after the correction.
Because your routine is concise, I will adopt it as well.
Thank you for your effort! 

Back to top 


Per Svensson
Joined: 03 Oct 2004 Posts: 190 Location: Gothenburg, Sweden

Posted: Thu May 14, 2020 11:12 am Post subject: 


Hi Mrshilov,
Thank you for this contribution.
Inspired by it, and also having a need for this sensor, I decided to make a floating point version of it and compare the results.
Attached you will find a test program and an include lib for Integer as well as Single
In my case, the interesting part is a very accurate air pressure resolution, as I will use it for measuring rock topografy variations.
Ideally it should , with aggressive filtering, be possible to discriminate down to 10cm or better.
As 1pascal is ~equivalent to 8cm at sea level I need fractions of 1 Pascal. Absolute accuracy is however not important so stability is key here.
To make a long story shorter. I took the datasheet formulas from Bosch and rewrote it to Bascom math.
I also wrote a short test program that is calling both float and integer compensation routines with the same data and calibration parameters to compare the outcomes.
So, Integer results basically comes from your code and FPresults from mine.
The data and calibration was extracted from the BME280 sensor I had handy.
Running the test:
RAWDATA: ADCp=310604.00 ADChum=30411.00 ADCt=535756.00
32bit FLOAT MATH > P=104591.05 Pa, Hum=32.60 %, T=25.57'C
CPU Load: 14715 cycles = 919.69 us at 16 MHz
16bit INTEGER MATH > P=100315 Pa, Hum=3259 %, T=2557'C
CPU Load: 8933 cycles = 558.31 us at 16 MHz
It can be seen that Humidity and Temperature agrees, but Pressure differ 1.5 Pascal.
Now, the question is. Is there an implementation mistake in on of the routines or is it just due to the higher accuracy in FPmath?
I really cannot tell, as there is no on line calculator from Bosch.
Perhaps there is someone in this forum who have another FPimplementation to run for comparison?
You can easily use my rawdata and calibration constants.
An excel sheet for the same thing would also be a good candidate...
/Per 

Back to top 


Per Svensson
Joined: 03 Oct 2004 Posts: 190 Location: Gothenburg, Sweden

Posted: Thu May 14, 2020 12:32 pm Post subject: 


Sorry for the typing mistake.
Pressure discrepancy should read 43hPa. Not 1.5Pa
(104591.05  100315 ~43276 Pa)
/Per 

Back to top 


Per Svensson
Joined: 03 Oct 2004 Posts: 190 Location: Gothenburg, Sweden

Posted: Thu May 14, 2020 2:06 pm Post subject: 


Ok, so I made this Excel calculations as well, and here are the results:
(Attached the excel sheet)
RAWDATA: ADCp=310604.00 ADChum=30411.00 ADCt=535756.00 (as before)
EXCEL MATH > P=100309.36 Pa, Hum=32.60 %, T=25.57'C
32bit FLOAT BASCOM MATH > P=104591.05 Pa, Hum=32.60 %, T=25.57'C
16bit INTEGER BASCOM MATH > P=100315 Pa, Hum=3259 %, T=2557'C
The conclusion is that the integer math is correct (although rougher that Excel)
My bascom version has a bug somewhere. I have to find it.
Stay tuned...
/Per 

Back to top 


OFamily
Joined: 23 May 2010 Posts: 169 Location: Japan


Back to top 


Per Svensson
Joined: 03 Oct 2004 Posts: 190 Location: Gothenburg, Sweden

Posted: Sun May 17, 2020 11:33 am Post subject: 


I rewrote the floating point for 64 bit double instead of 32 bit single.
The 32 bot code was not performing better that the integer code, even after finding the bug.
The results with double precision math is nearly as accurate as of Excel as you can see here below, but of course much
slower than using integer math. About three times.
RAWDATA: ADCp=310604.00 ADChum=30411.00 ADCt=535756.00 (as before)
EXCEL MATH > P=100314,1123 Pa, Hum=32.60 %, T=25.57'C
BASCOM: 64bit FLOAT MATH > P=100314.11 Pa, Hum=32.60 %, T=25.57'C
CPU Load: 28820 cycles = 1801.25 us at 16 MHz
BASCOM: 16bit INTEGER MATH > P=100315 Pa, Hum=3259 %, T=2557'C
CPU Load: 8933 cycles = 558.31 us at 16 MHz
Now, the next step is to do a lot of sampling over an extended time in controlled atmosphere (Pressure and/or Temp),
and run statistics on it to see if the high floating point accuracy is worth the price. It might be that Bosch's calibration parameters are
less useful after soldering and aging. Heavy averaging of data is meaningless if the linearization of the raw data does not work
and proves to be in excess of random sensor noise.
Stay tuned... 

Back to top 


Per Svensson
Joined: 03 Oct 2004 Posts: 190 Location: Gothenburg, Sweden

Posted: Thu May 21, 2020 11:07 pm Post subject: 


Here is an update of the Bascom code for correction of data from BME280 and the companion Excel sheet.
I also made a series of data sampling for 5 hours at 1Hz.
There are five reports from this run (Pdf's)
 Raw Pressure data from the BME280 adc.
 Compensated pressure data using 32bit integer math
 Compensated pressure data using FP64 double math
 Compensated Temperature using FP32 (single) math
 Compensated Humidity data using FP32 single math
Each file contains statistics like plots of values versus time and spectrum density.
Most interesting is the Allan Variance plot of the 64 bit floating point data.
It shows 0.20.6 Pascal short time stability (Standard deviation) (for variance taken in the interval up to ten seconds.
then for longer times stability seem rather poor…. Or is it?
It is not easy to distinguish real atmospheric pressure variations from inherent sensor drift (Random walk)...
To further get a clue if the temperature correction really works as intended I made a test (data not included here) where sensor temperatur was ramped up from 25 degrees to 36, and then back again. I used 4 hours sampling at 1 Hz. The result clearly shows that the raw pressure data closely follows the temperature curve, whilst the
compensated curve shows no obvious correlation to temperature. This indicates that the compensation math does a pretty good job.
Furthermore, the pressure curve follows rather well the pressure curves from the Swedish Metereological Institute for the time at hand.
My conclusion is that the BME280 sensor can be used for resolving atmospheric pressure variations around 0.51 Pascal which correspond to 48cm of altitude change.
The real challenge, using the device for altitude measurements, is not the resolution or accuracy of the sensor as such . The challenge is to reject the natural air pressure variations, also for rather short time periods. The pressure can sometimes vary 100 pascals over one hour. which is 8m error (!)
The only remedy is to set up a reference sensor at a known altitude and take the difference between this and the "rover", to noll out the weather factor.
Alternatively, to keep contact with another reference station over radio or internet and use that for "weather compensation".
Observe though, that heavy lowpass filtering by averaging (runningaverage) is mandatory to get good noise performance for this particular task, where speed is of no interest.
In my real application I have set up the sensor for maximum filtering, and also used som additional running average to supress noise. But this is not shown in the test file in the zip.
Another conclusion is that unless you need lowest possible noise, the 32bit integer compensation math, originally coded by Mrshilov will serve most needs very well.
And speed is superior, as stated earlier. Three timed the speed of 64 bit floating point math.
Enough of this for now.
Comment are as usual welcome. and don't forget to be out in the sun. Coding is fun but tan is better…
/Per 

Back to top 




You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum

