I think I had that sort of problem with the casting as well. Not sure now, it was a couple of years ago. It took a while to get it to work, I went through all those shift manipulations looking very closely at the bosch description. It appears that some of the library code that people published for this device, they never even tried running it.
I also recall seeing somewhere, an alternative processing scheme that someone devised, which used float instead of int ( or maybe the other way around ), to get an output with less bit errors in it. It looked very interesting but I did not implement it.
The Adafruit library allows you to put in a base altitude for more accurate altitude above sea level readings as that library also provides an altitude calculation. It has zero effect on the accuracy of anything else.
It also is no good for compensating any weather effects, so is more for experimentation - it is better to use a sample "ground level at now" and then measure differences rather than ever try to somehow measure an absolute above sea level with just a pressure sensor alone.
Normally if "altitude matters" you want to measure how high something went, or how high above the ground you are in the real time space, not how high above some arbitrary (sea level) number you are. You can always factor in the arbitrary number at another non-realtime time later if need be - well, according to my two cents anyway.
Arduino Pro Mini 5v 16MHz 328 (Maybe the 328 is key here? Unsure why it would be a major difference other than ram space although I find more and more quirks with the arduino compiler as I go...)
Bosch BMP180 sensor on breakout with 3v3 supply (ebay special)
Various other i2c devices not currently in use in test code (now in use in full code, and happily co-existing), other than the oLED used as the debug display (rather than serial terminal)
So essentially the same setup as I'm using except that mine are Pro Mini 3.3v boards.
Now, since I want to understand this to the fullest I'd like you to post your sensor variables for me please
askjacob:
...
By the way - I popped over to your website to see if there was any updated code, and instead was enthalled by the rocketry and altimeter stuff - amazing stuff
Thanks very much mate
Now imagine if I had the problem with my altimeter (I'm using the Bosch sensor in one of them) I'd be in serious trouble. Rockets aren't very forgiving. Either everything works out 100% or your doomed.
OK, my values ADDED IN ABOVE. Just to eliminate the chance of i2c corruption, I did a few cold boots and verified these remained unchanged (other of course, than UP and UT). I think these numbers are pretty wild - probably why they are on ebay rather than digikey, making them edge cases for the formula hence why they push the envelope and finding where the gap is.
Incidentally, digging in the Adafruit libaray C file I find this:
Well I also check the .cpp's adafruit library file and they cast others variables as int32_t or uint32_t in that function ( readPressure)
If I force all as you suggest for b3 the result is similar to the one in the local weather station, similar to the result if i use adafruit example.
If I only change the one for b3 I have a low pressure value, don't remember now but it was like 2XX mbar
I try it on Leonardo and Nano (5v) and it looks the same.
I added them in in an edit in reply #20. Getting all the values out is a pain, as I only have a 128x64 display, so I have to do a few custom screens/loads with just a basic framework rather than my usual application.
Sure does - especially across 2 devices showing the same issue. I have 4 more sensors here now I can try out and see what the result is.
Strange enough though, once I modified the b3= line, it behaves itself properly - or - well enough. Again, it is more likely why these are on ebay far cheaper on a breakout board than from a reputable supplier in x5000 piece prices... they are probably from the reject bin as even with maxxed out compensation values they could not get them to true spec...
askjacob:
Sure does - especially across 2 devices showing the same issue. I have 4 more sensors here now I can try out and see what the result is.
Strange enough though, once I modified the b3= line, it behaves itself properly - or - well enough. Again, it is more likely why these are on ebay far cheaper on a breakout board than from a reputable supplier in x5000 piece prices... they are probably from the reject bin as even with maxxed out compensation values they could not get them to true spec...
Cheers
Jacob
MB = -32768
Looking back - it seems this one is the same across all devices - even Leo's one is the same value - unless he is using ehrja's data. Maybe it is not really a often tweaked value?
Hmm maybe that one is not the smoking gun here! I will hook up some of my other sensors and see.
OK I tried 2 more sensors, same result. Without the modified line, I get almost 500 mbar above the correct reading. They all read within about .2 mbar of each other though which is not bad considering the price...
The Adafruit library allows you to put in a base altitude for more accurate altitude above sea level readings as that library also provides an altitude calculation. It has zero effect on the accuracy of anything else.
It also is no good for compensating any weather effects, so is more for experimentation - it is better to use a sample "ground level at now" and then measure differences rather than ever try to somehow measure an absolute above sea level with just a pressure sensor alone.
Normally if "altitude matters" you want to measure how high something went, or how high above the ground you are in the real time space, not how high above some arbitrary (sea level) number you are. You can always factor in the arbitrary number at another non-realtime time later if need be - well, according to my two cents anyway.
That's all true, but then this "provided altitude" is coming from you, or it is written into the sketch somewhere. It's not coming from the sensor.
My advice would be to implement a sketch which does two things and two things only. Read the data registers from the chip. Implement the conversion algorithm as defined by Bosch.
If you want to "compensate" for the air pressure at the airport, or the known reference altitude, then do that later.
Looking at the code I have here, I seem to have two different versions of the temperature calculation, which are different. I had to "fix" it, for some reason, which I don't fully recall now.
I am not 100% certain, but it appears that the first calculation is the wrong one, and the second one is correct.
My advice would be to implement a sketch which does two things and two things only. Read the data registers from the chip. Implement the conversion algorithm as defined by Bosch.
Yep, and the code from Leo does just that - it is pretty much stock. The issue stems from the sample code from Bosch not being explicit with casting in the example, and how the Arduino environment handles it. The Bosch datasheet mentions the data types returned for the registers, but not what is expected within the sample code itself - just that c++ handles it 'properly'... and it seems to for some people or most cases.
The Adafruit one is similar (but has nested if statements to handle the BMP085 as well as casting all over the place) so is much harder to to map back to the original algorithm.
So much fun for what I was hoping for a 'simple' datalogging application I am working on..
The sensors which have a big value for AC1, don't work, because AC1 x 4 will overflow in the calculation of B3, because it is performing a 16 bit calculation there, unless you tell it otherwise.
But if the sensor happens to have small value of AC1, you don't get this problem, because it still fits in 16 bits.
You will observe that in Bosch's calculation, AC1 is 408 and Leo's example ha 408 also, but Jacob and Erhja have 8000 and 9000 there, which will overflow when multiplied by 4.