Yes datasheets do contain mistakes which can be very confusing. There are no mistakes in the equations because Adruino etc use the same ones and they work.
If you only want temperature there are a number of low cost devices, DS18B20, TMP36 and the simple thermistor all work well. For temp + hum there's DHT11, DHT22 + varients and HTU21D (I haven't used one) there's also another that costs about £20 & I definitely haven't used that. I was initially put off of BME280 because it's 3.3V, but it's supposed to be very accurate and reliable and is low cost. It was becoming very popular for Arduino, so I kept looking. Over the years I've notice that I like a mental challenge, I once I figure something out, I'm on to the next challenge. I spent several weeks figuring out how to make a central heating valve controller using electronics and a stepper motor. After I'd figured it out and proved the circuitry worked, I decided the benefits where so minimal that it wasn't worth the effort of making a prototype! However I'm now up to speed with Photo Transistors, I/R sensors and A/C to D/C convertors etc.
I was right about converting the Proton code, I'm breezing through, stuff that was initial incomprehensible now makes complete sense. Proton is good,although its syntax is IMO quite different. It can receive I2C or SPI data in a variety of sizes. E.g. Pressure, Temp and Humidity it receives as a complete Word + 2 .xlsb bytes for Press & Temp. I'm not sure how it handles the byte components, there's alot of "bit swaping" in the code so maybe it doesn't do that too well.
That's to find out later.
I've noticed while evaluating different Basic Compilers that there's always something that one can do really well but the others can't.
Last edit: David Thompson 2017-11-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've made a start and I'm now getting data from the 16F. As expected it goes tilt if I try to use P,T & H, the Pressure calculations are just too big for 8k of flash.
Proton's handling of Word/Long components is similar to gcb so not sure why Swap is used, possibly less memory use than Dimensions or maybe the author was more familiar with Swap. As mentioned above all the brain ache is now worthwhile. The digital analyser is really brilliant for figuring out what's happening when either nothing or an unexpected result occurs. Using SPI Receive, GCB, Oshonsoft and Proton all work differently at least from the IDE end of things. Without the analyser it would be extremely difficult to figure out what's happening. You can also see how the data is being sent. Some data seems back to front e.g. 0xDE8E vs 0x8EDE, this is what all the Swapping was about. Probably just the X_E, X_U, X_H and Byte[X] stuff, Ineed to check that later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I've cracked it. I was getting completly different calib data using Proton and no PTH data at all, even though I could see it on the digital analyser. I tried Oshonsoft, the output was almost the same as GCB just H4 different. Tried to match the Proton variables to Osh which has Foats. Added the equation (broken into 4 parts) it worked, removed the Floats, it still worked! I matched the variables in GCB and that worked too!
I tried to simplify the Osh code for H4, although the new code looked OK, it really screwed up the result. I need to check if something similar is happening in GCB.
At the moment I've got H4 = 9 (Osh) and H4 = 0 (GCB), everything else is the same.
I also need to see what happens with Negative Temperature, which ought to be reasonably easy. Then I'll tidy up and comment the code, not much point in adding Pressure yet, it won't fit on the 16F887. I'll try that with a Mega328P after a lay down for several weeks ;-)
Mike, did you manage to get Pressure sorted out?
I can see now that the broken down equation I found on the Bosch site won't work without Floats. it has something like VarP = 1-(xxx*xxx/xxx) etc, anything less than 1 can only be zero with integers so this is no use.
It's like we said along time ago, unless you understand the eqation you can't figure out what variable types will work.
Anyone got any vacancies for a Bosch BME280 DS recital :-)
Anobium I'll upload the Max7219/21 code if you still want it, I've been too engrosed in BME stuff.
IK here it is, still haven't checked negative temp
David T,
I have been distracted with getting ready for family coming for Thanksgiving and hamradio Sweepstakes contest and problems with a 25 hp scr drive.
So i plugged the board in to see my TPH this morning and nothing was working. Most bothersome is the configuration parameters were coming back different. Dig_Ts were 0 and the Dig_H1 was 96 instead of 75. I tried the other boards and they all said 96?? This goes back to the interface? I thought i solved that by buying boards with built in interface.
Never the less, I looked at your code and first thing that struck me was you are using words for the configuration parameters when you could be using integers which are signed words. Of course they are not all signed. This code is what i am using now. Please correct me if you see something wrong.
dim dig_T1 as word
dim dig_T2 ,dig_T3 as Integer
dim dig_P1 as word
dim dig_P2, dig_P3, dig_P4, dig_P5, dig_P6, dig_P7, dig_P8, dig_P9 as integer
dim dig_H1,dig_H3,dig_H6 as byte
dim dig_H2, dig_H4, dig_H5 as Integer
I will try your code and compare with mine.
I had been moving all the code into the BME280.h library. Putting it in routines helps not hitting the memory limit on page 1. I have code for TPH and just now compiled it.
8.7 Sec. Compiler Version: 0.98.00 2017-09-23 Program Memory: 6922/8192 words (84.5%) RAM: 228/368 bytes (61.96%) Chip: 16F886
So it is getting up there but there is lots of room.
I am not confident of my code because when I switch between BME280 modules( 3 different ones) I don't get similar results. This code needs more work. And Now one of the config values changed? What's up?
Plugging away,
BR
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The logic for using Long isn't logical. Proton has SWORD but it's SPI was reading very strange and I couldn't see how to fix it. Oshonsoft has Single(Floats) but doesn't have Integer/Sword so I used Long so it had plenty of room! Single didn't help much, just 7 extra numbers after the "."
When I transferred back to GCB I stayed with what worked. I guess the next step is to change them and check how iti affects the result. IMO the BME Humidity seems a bit low, maybe use 1000 instead 1024 at the end, that would be closer to my commercial Digital Humidity Meter. Apparently humidity can exceed 100% in special circumstances, Inside a superheated steam chamber at 200C/392F perhaps? Humidity in home use stuff is not know for it's accuracy. I have AM2302s & DT22s that can be 10% apart, their spec is +/- 2% up to +/-5%. The BME is +/3%
Some of the code is now in subs to avoid "Page Full". I'll transfer to mega328P before continuing with Pressure.
I think I'll have a few days off before I do any more.
Enjoy Thanksgiving.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Humidy does not work! The equation calculation needs another break. Also H4 is wrong.
I get H4=296 with Oshonsoft = 11% and H4 = 8 with GCB which just doesn't work.
Manual entry h4 = 296 with GCB = 11%
Looks like SPI problem, so more research with the Data Analyser, which is still connected.
Who mocked a wet finger held in the air?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Stan and David,
I read the Picaxe posting that you refered too and gather that they are no futher ahead than we are. One small idea was that they had the I2C clock at 100 and I have been running at 400. So I had to try that.
My newest problem is that that a couple of the calibration parameters have changed on each of the three test BME280 modules. All three modules plug into the same soldered protoboard with a pic16F886, one at a time. They all have build in voltage regulator and voltage translators. I have pull up resistors for the I2C lines. I read all the T&P calib parameters with one read. Humidity takes 2 reads. The reading procedure has not changed since I found the cut and paste error at the beginning of Nov.
11/9/2017
num 1 module
Dig_T =28361,26162,-5582
Dig_P =36586,-10600,3024,15141,-1537,3327,8240,-30511,7936
Dig_H= 75,327,0,414,50,166
num 2 module
Dig_T= 28622,26445,12082
Dig_P=35631,-10553,3024,-2015,-1537,3327,8240,-30511,7936
Dig_H=75,326,0,421,50,114
num 3 module
Dig_T = 28177,26372,28978
Dig_P=36721,-10561,3024,32543,-1537,3327,8240,-30511,7936
Dig_H= 75,326,0,421,50,137
Now
Dig_P9 changed from 7936 to 6400
Dig_H1 changed from 75 to 96
The others stayed the same.
I changed the I2C speed and that didn't make any difference.
Calib constants should stay constant.
I need to put the Logic analyazer on.
73
mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well I've sort of fixed the problem. The code used to split .LB H4 & H5 from a single byte was wrong. Oshonsoft is very limited in its Bit Wise operations so the code is totaly different.
I'm amazed at how difficult it is to split a byte in two and reassign the nibbles. I now have both Basic varients producing the same result and agreeing with the data analyser. The SPICLK FOSC made no difference.
The "sort of fixed" is that both return 10% humidity while my commercial humidity monitor shows 42%. The fix is very technical, I multiply the result by 4! Humidity is quite responsive and a gentle "haw" will send it up, the response is similar to the commercial version.
So fixed but a very unsatisfactory fix.
Mike I changed the necessary variables to Integer and as I suspected it makes no difference.
Oshonsoft doesn't have any signed variables and the output is the same. I'll try and remember to check the zero point for temperature and code negaive handling.
I'll attach the code when I've done that. I'm definitely feeling "burn out" on this project so it may be a day or two.
Should have gone to SpecSavers! I've just had a look at ADC_T it's not linear. The number increments down to 0C at about decimal 454128 but at 454106 when it should be negative it gives 409.6C .Looks like Signed variables need investigating. It also explains why I'm having so much trouble with Humidity, T_fine is derived from adc_t and is used to calculate Humidity.
Back to the drawing board.
Well all this grief is not without benefit, I went back to Proton Basic and quickly solved my earlier problems. Just one biggy no sensor output, just a repeating pattern of 0,0,128 decimal.
I've posted on the Proton Forum to see if there's a solution.
If not I think I'll retire from this project, it's easier to learn how to make Arduino work with my peripherals.
Attached is my "debug" code which has lots of HSERPrints
Welcome to Great Cow Basic forum! It is an open forum.
I started with the BMP280 but am using 3x BME280's for testing and developement of a library for the GCB community. It will include the BMP280.
This has been a 2 month trek so far and some days i feel the end is near and some days I feel duped. Some new eyes would be welcomed. Please help if you can.
here is the current codes. GCB names the libraries as .h files.
Hi
It's been a while since I looked in. I think that the method of reading data and writing to confiuration registers has been sorted. The BIG problem is getting the "C" based data conversion Math to work. I've tried GCB, Oshonosoft & Proton albeit with a PIC16f886 and I can't get any of them to work. So after much effort I gave up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As an alternative to the BMP280 I am currently trying a MS5837. On the face of it the calculations in the datasheet look simpler (but have a certain similarity to those for the BMP280). I am suspecting that is the same sensor in a different package.
I am getting unacceptable rounding errors using 32-bit instead of the recommended 64-bit numbers.
It is however much easier to solder as it only has 4 pins (Vdd,Vss,CLK,DAT)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. I am on the job. This is still the next item on my project list. If I
cannot not fix it... I will move to the next item on my list. :-)
I hope it is a recursive list then :)
"As an alternative to the BMP280 I am currently trying a MS5837. "
...I don't get stuff working either David but I just give up and move on. Someone will do a math macro for c math in gcb v3.98.. hopefully. Good luck, I gave up with touch screen as example lib is floats. I'm doing ssd1306 to composite video, it's all timing stuff it seems...and whole nubers :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I actually got the BMP280 to work (temperature and pressure), but I did not get round to testing for all senarios (it cetainly works at "normal" temperatures and pressures). The details are in another thread.
I was trying out the MS5837 as it seems much easier to solder just 4 pins at the corners
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes datasheets do contain mistakes which can be very confusing. There are no mistakes in the equations because Adruino etc use the same ones and they work.
If you only want temperature there are a number of low cost devices, DS18B20, TMP36 and the simple thermistor all work well. For temp + hum there's DHT11, DHT22 + varients and HTU21D (I haven't used one) there's also another that costs about £20 & I definitely haven't used that. I was initially put off of BME280 because it's 3.3V, but it's supposed to be very accurate and reliable and is low cost. It was becoming very popular for Arduino, so I kept looking. Over the years I've notice that I like a mental challenge, I once I figure something out, I'm on to the next challenge. I spent several weeks figuring out how to make a central heating valve controller using electronics and a stepper motor. After I'd figured it out and proved the circuitry worked, I decided the benefits where so minimal that it wasn't worth the effort of making a prototype! However I'm now up to speed with Photo Transistors, I/R sensors and A/C to D/C convertors etc.
I was right about converting the Proton code, I'm breezing through, stuff that was initial incomprehensible now makes complete sense. Proton is good,although its syntax is IMO quite different. It can receive I2C or SPI data in a variety of sizes. E.g. Pressure, Temp and Humidity it receives as a complete Word + 2 .xlsb bytes for Press & Temp. I'm not sure how it handles the byte components, there's alot of "bit swaping" in the code so maybe it doesn't do that too well.
That's to find out later.
I've noticed while evaluating different Basic Compilers that there's always something that one can do really well but the others can't.
Last edit: David Thompson 2017-11-17
I've made a start and I'm now getting data from the 16F. As expected it goes tilt if I try to use P,T & H, the Pressure calculations are just too big for 8k of flash.
Proton's handling of Word/Long components is similar to gcb so not sure why Swap is used, possibly less memory use than Dimensions or maybe the author was more familiar with Swap. As mentioned above all the brain ache is now worthwhile. The digital analyser is really brilliant for figuring out what's happening when either nothing or an unexpected result occurs. Using SPI Receive, GCB, Oshonsoft and Proton all work differently at least from the IDE end of things. Without the analyser it would be extremely difficult to figure out what's happening. You can also see how the data is being sent. Some data seems back to front e.g. 0xDE8E vs 0x8EDE, this is what all the Swapping was about. Probably just the X_E, X_U, X_H and Byte[X] stuff, Ineed to check that later.
I think I've cracked it. I was getting completly different calib data using Proton and no PTH data at all, even though I could see it on the digital analyser. I tried Oshonsoft, the output was almost the same as GCB just H4 different. Tried to match the Proton variables to Osh which has Foats. Added the equation (broken into 4 parts) it worked, removed the Floats, it still worked! I matched the variables in GCB and that worked too!
I tried to simplify the Osh code for H4, although the new code looked OK, it really screwed up the result. I need to check if something similar is happening in GCB.
At the moment I've got H4 = 9 (Osh) and H4 = 0 (GCB), everything else is the same.
I also need to see what happens with Negative Temperature, which ought to be reasonably easy. Then I'll tidy up and comment the code, not much point in adding Pressure yet, it won't fit on the 16F887. I'll try that with a Mega328P after a lay down for several weeks ;-)
Mike, did you manage to get Pressure sorted out?
I can see now that the broken down equation I found on the Bosch site won't work without Floats. it has something like VarP = 1-(xxx*xxx/xxx) etc, anything less than 1 can only be zero with integers so this is no use.
It's like we said along time ago, unless you understand the eqation you can't figure out what variable types will work.
Anyone got any vacancies for a Bosch BME280 DS recital :-)
Anobium I'll upload the Max7219/21 code if you still want it, I've been too engrosed in BME stuff.
IK here it is, still haven't checked negative temp
Last edit: David Thompson 2017-11-21
David T,
I have been distracted with getting ready for family coming for Thanksgiving and hamradio Sweepstakes contest and problems with a 25 hp scr drive.
So i plugged the board in to see my TPH this morning and nothing was working. Most bothersome is the configuration parameters were coming back different. Dig_Ts were 0 and the Dig_H1 was 96 instead of 75. I tried the other boards and they all said 96?? This goes back to the interface? I thought i solved that by buying boards with built in interface.
Never the less, I looked at your code and first thing that struck me was you are using words for the configuration parameters when you could be using integers which are signed words. Of course they are not all signed. This code is what i am using now. Please correct me if you see something wrong.
I will try your code and compare with mine.
I had been moving all the code into the BME280.h library. Putting it in routines helps not hitting the memory limit on page 1. I have code for TPH and just now compiled it.
So it is getting up there but there is lots of room.
I am not confident of my code because when I switch between BME280 modules( 3 different ones) I don't get similar results. This code needs more work. And Now one of the config values changed? What's up?
Plugging away,
BR
Mike
The logic for using Long isn't logical. Proton has SWORD but it's SPI was reading very strange and I couldn't see how to fix it. Oshonsoft has Single(Floats) but doesn't have Integer/Sword so I used Long so it had plenty of room! Single didn't help much, just 7 extra numbers after the "."
When I transferred back to GCB I stayed with what worked. I guess the next step is to change them and check how iti affects the result. IMO the BME Humidity seems a bit low, maybe use 1000 instead 1024 at the end, that would be closer to my commercial Digital Humidity Meter. Apparently humidity can exceed 100% in special circumstances, Inside a superheated steam chamber at 200C/392F perhaps? Humidity in home use stuff is not know for it's accuracy. I have AM2302s & DT22s that can be 10% apart, their spec is +/- 2% up to +/-5%. The BME is +/3%
Some of the code is now in subs to avoid "Page Full". I'll transfer to mega328P before continuing with Pressure.
I think I'll have a few days off before I do any more.
Enjoy Thanksgiving.
Page Full Error is fixed in v0.98.02
The picaxe guys are doing it for them selves or summat http://www.picaxeforum.co.uk/showthread.php?30367-32-bit-maths-routines-for-BMP180-BMP280-and-BME280-Atmospheric-sensors
Humidy does not work! The equation calculation needs another break. Also H4 is wrong.
I get H4=296 with Oshonsoft = 11% and H4 = 8 with GCB which just doesn't work.
Manual entry h4 = 296 with GCB = 11%
Looks like SPI problem, so more research with the Data Analyser, which is still connected.
Who mocked a wet finger held in the air?
does it conduct like water at 0C? is it near 0C? does it reflect light?
could be snow
Stan and David,
I read the Picaxe posting that you refered too and gather that they are no futher ahead than we are. One small idea was that they had the I2C clock at 100 and I have been running at 400. So I had to try that.
My newest problem is that that a couple of the calibration parameters have changed on each of the three test BME280 modules. All three modules plug into the same soldered protoboard with a pic16F886, one at a time. They all have build in voltage regulator and voltage translators. I have pull up resistors for the I2C lines. I read all the T&P calib parameters with one read. Humidity takes 2 reads. The reading procedure has not changed since I found the cut and paste error at the beginning of Nov.
11/9/2017
num 1 module
Dig_T =28361,26162,-5582
Dig_P =36586,-10600,3024,15141,-1537,3327,8240,-30511,7936
Dig_H= 75,327,0,414,50,166
num 2 module
Dig_T= 28622,26445,12082
Dig_P=35631,-10553,3024,-2015,-1537,3327,8240,-30511,7936
Dig_H=75,326,0,421,50,114
num 3 module
Dig_T = 28177,26372,28978
Dig_P=36721,-10561,3024,32543,-1537,3327,8240,-30511,7936
Dig_H= 75,326,0,421,50,137
Now
Dig_P9 changed from 7936 to 6400
Dig_H1 changed from 75 to 96
The others stayed the same.
I changed the I2C speed and that didn't make any difference.
Calib constants should stay constant.
I need to put the Logic analyazer on.
73
mike
Well I've sort of fixed the problem. The code used to split .LB H4 & H5 from a single byte was wrong. Oshonsoft is very limited in its Bit Wise operations so the code is totaly different.
I'm amazed at how difficult it is to split a byte in two and reassign the nibbles. I now have both Basic varients producing the same result and agreeing with the data analyser. The SPICLK FOSC made no difference.
The "sort of fixed" is that both return 10% humidity while my commercial humidity monitor shows 42%. The fix is very technical, I multiply the result by 4! Humidity is quite responsive and a gentle "haw" will send it up, the response is similar to the commercial version.
So fixed but a very unsatisfactory fix.
Mike I changed the necessary variables to Integer and as I suspected it makes no difference.
Oshonsoft doesn't have any signed variables and the output is the same. I'll try and remember to check the zero point for temperature and code negaive handling.
I'll attach the code when I've done that. I'm definitely feeling "burn out" on this project so it may be a day or two.
Should have gone to SpecSavers! I've just had a look at ADC_T it's not linear. The number increments down to 0C at about decimal 454128 but at 454106 when it should be negative it gives 409.6C .Looks like Signed variables need investigating. It also explains why I'm having so much trouble with Humidity, T_fine is derived from adc_t and is used to calculate Humidity.
Back to the drawing board.
Well all this grief is not without benefit, I went back to Proton Basic and quickly solved my earlier problems. Just one biggy no sensor output, just a repeating pattern of 0,0,128 decimal.
I've posted on the Proton Forum to see if there's a solution.
If not I think I'll retire from this project, it's easier to learn how to make Arduino work with my peripherals.
Attached is my "debug" code which has lots of HSERPrints
Last edit: David Thompson 2017-11-29
Hi,
Just found your discussion, as I'm working on something smilar here: http://www.electro-tech-online.com/threads/pic-with-5110-48x84-lcd-screen.150378/
Is it ok to join in? although I'm not much of a programmer. Also is it ok to 'borrow' your code for my projects? I'm using BMP280s.
Cheers, Camerart
Greetings Camerart,
Welcome to Great Cow Basic forum! It is an open forum.
I started with the BMP280 but am using 3x BME280's for testing and developement of a library for the GCB community. It will include the BMP280.
This has been a 2 month trek so far and some days i feel the end is near and some days I feel duped. Some new eyes would be welcomed. Please help if you can.
here is the current codes. GCB names the libraries as .h files.
Last edit: mmotte 2017-12-13
Can someone summarise where this library and code is at?
Do we have a driver for the BME/BMP280 and the BMP180 Barometric Pressure and Temperature Sensors?
I have to admit I do not know but I have a BME/BMP280 and a BMP180 Barometric Pressure and Temperature Sensor sitting here to test.
Can someone advise please.
Hi
It's been a while since I looked in. I think that the method of reading data and writing to confiuration registers has been sorted. The BIG problem is getting the "C" based data conversion Math to work. I've tried GCB, Oshonosoft & Proton albeit with a PIC16f886 and I can't get any of them to work. So after much effort I gave up.
OK. I am on the job. This is the next item on my project list. If I cannot not fix it... I will move to the next item on my list. :-)
As an alternative to the BMP280 I am currently trying a MS5837. On the face of it the calculations in the datasheet look simpler (but have a certain similarity to those for the BMP280). I am suspecting that is the same sensor in a different package.
I am getting unacceptable rounding errors using 32-bit instead of the recommended 64-bit numbers.
It is however much easier to solder as it only has 4 pins (Vdd,Vss,CLK,DAT)
OK. I am on the job. This is still the next item on my project list. If I cannot not fix it... I will move to the next item on my list. :-)
OK. I am on the job. This is still the next item on my project list. If I cannot not fix it... I will move to the next item on my list. :-)
See https://sourceforge.net/p/gcbasic/discussion/579125/thread/3275193c/#4cea/ad63
"As an alternative to the BMP280 I am currently trying a MS5837. "
...I don't get stuff working either David but I just give up and move on. Someone will do a math macro for c math in gcb v3.98.. hopefully. Good luck, I gave up with touch screen as example lib is floats. I'm doing ssd1306 to composite video, it's all timing stuff it seems...and whole nubers :)
I actually got the BMP280 to work (temperature and pressure), but I did not get round to testing for all senarios (it cetainly works at "normal" temperatures and pressures). The details are in another thread.
I was trying out the MS5837 as it seems much easier to solder just 4 pins at the corners
Can you post your code? We seem to different successes so this will help
Some of the register files could do with checking as I can't seem to get the filters to work.
I am confused. Is this the code that works? or, do you have other code that works (with the range constraint).
Cheers