Forum - MCS Electronics

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.
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
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
O-Family

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!

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
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.
O-Family

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!
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 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
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
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
O-Family

Joined: 23 May 2010
Posts: 169
Location: Japan

 Posted: Fri May 15, 2020 3:53 am    Post subject: 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
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...
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.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… /Per
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First
 All times are GMT + 1 Hour Page 1 of 1

 Jump to: Select a forum BASCOM AVR/8051----------------BASCOM-AVRBASCOM-8051BASCOM-ARDUINOShare your working BASCOM-8051 code hereShare your working BASCOM-AVR code hereBASCOM BETA-SLA BASCOM Related----------------EASY TCP/IPAVR-DOSAR7212KokkeKat FAT-free SD card libBASCOM Project Blog Other Stuff----------------VariousPCB'sRoboticsNew WebSiteAnnouncementsAVR Archive----------------BASCOM-AVR ArchiveBASCOM-8051 ArchiveBASCOM-AVR Unsupported versionsEasy TCP/IP ArchiveBASCOM-EDB
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