Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

BME280 sensor

 
Post new topic   Reply to topic    www.mcselec.com Forum Index -> Share your working BASCOM-AVR code here
View previous topic :: View next topic  
Author Message
Mrshilov

Bascom LCD Guru



Joined: 24 Jan 2009
Posts: 314
Location: Russia

russia.gif
PostPosted: Tue Dec 15, 2015 1:41 pm    Post subject: BME280 sensor Reply with quote

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
View user's profile
aphawk

Bascom Member



Joined: 23 Jan 2010
Posts: 155
Location: Brazil

brazil.gif
PostPosted: Wed Dec 16, 2015 1:29 am    Post subject: Reply with quote

Mrshilov,

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

Paulo
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 4970
Location: Holland

blank.gif
PostPosted: Thu Dec 17, 2015 10:22 am    Post subject: Reply with quote

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
View user's profile Visit poster's website
O-Family

Bascom Expert



Joined: 23 May 2010
Posts: 173
Location: Japan

japan.gif
PostPosted: Thu Mar 16, 2017 11:15 am    Post subject: Reply with quote

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
View user's profile Visit poster's website
Mrshilov

Bascom LCD Guru



Joined: 24 Jan 2009
Posts: 314
Location: Russia

russia.gif
PostPosted: Thu Mar 16, 2017 1:40 pm    Post subject: Reply with quote

Yes, you are right - it's wrong. Also I find another error in hum procedure. In attachment corrected version & proteus model.
Back to top
View user's profile
O-Family

Bascom Expert



Joined: 23 May 2010
Posts: 173
Location: Japan

japan.gif
PostPosted: Fri Mar 17, 2017 11:35 am    Post subject: Reply with quote

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
View user's profile Visit poster's website
Per Svensson

Bascom Member



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

sweden.gif
PostPosted: Thu May 14, 2020 11:12 am    Post subject: Reply with quote

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 FP-results 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 FP-math?
I really cannot tell, as there is no on line calculator from Bosch.
Perhaps there is someone in this forum who have another FP-implementation 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
View user's profile Visit poster's website
Per Svensson

Bascom Member



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

sweden.gif
PostPosted: Thu May 14, 2020 12:32 pm    Post subject: Reply with quote

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

/Per
Back to top
View user's profile Visit poster's website
Per Svensson

Bascom Member



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

sweden.gif
PostPosted: Thu May 14, 2020 2:06 pm    Post subject: Reply with quote

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
View user's profile Visit poster's website
O-Family

Bascom Expert



Joined: 23 May 2010
Posts: 173
Location: Japan

japan.gif
PostPosted: Fri May 15, 2020 3:53 am    Post subject: Reply with quote

The BME280 program created by Mrshilov and the measurement results of different pressure sensors [LPS331AP], [LPS25H], [MPL115A2], [MPL115A1] were also within the difference of 2hPa-10hPa.

The BME280 is a compound sensor, so I think it's not very accurate.

In addition, moving averages are important because minute air pressure values change with wind and the degree to which doors are opened and closed.
Although it does not provide sufficient accuracy, it can capture changes in height difference of about 10cm.
https://www.youtube.com/watch?v=LBJcptDYFUk&feature=youtu.be

http://translate.google.com/translate?hl=ja&sl=ja&tl=en&u=http%3A%2F%2Fwww.ne.jp%2Fasahi%2Fshared%2Fo-family%2FElecRoom%2FAVRMCOM%2FBME280%2FBME280_SK2.html&sandbox=1
http://www.ne.jp/asahi/shared/o-family/ElecRoom/AVRMCOM/BME280/BME280_SK2.html
Back to top
View user's profile Visit poster's website
Per Svensson

Bascom Member



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

sweden.gif
PostPosted: Sun May 17, 2020 11:33 am    Post subject: Reply with quote

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
View user's profile Visit poster's website
Per Svensson

Bascom Member



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

sweden.gif
PostPosted: Thu May 21, 2020 11:07 pm    Post subject: Reply with quote

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.2-0.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.5-1 Pascal which correspond to 4-8cm 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 (running-average) 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… Smile

/Per
Back to top
View user's profile Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    www.mcselec.com Forum Index -> Share your working BASCOM-AVR code here All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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