The ting is that I plugged it into an arduino leonardo using 5 v, then reading the datasheet I realized that it has to be 3.3v so I change it, fortunately the sketch wasn't loaded and the arduino totally ignore the sensor so it will not work any way because the arduino did not start it.
then I load the example of the sparkfun library of the BMP180 sensor and the serial give me data:
So it is working normally
The temperature was ok hire is hoot right now. but the elevation of my city is 10 - 30 meters over sea level.
I don't know if I'm misunderstanding the provided altitude (1655 m) or if the sensor was damaged by the 5v in "Standby mode" or is because of the 5 v of the arduino IIC pins.
the @sparkfun code and the one posted by @Leo gave me different data as you can see if you check my first post in each treat, I post the corresponding results of different codes in each treat, well... I din't notice that the inHg was really different for each code results, just notice that the data was to much to be true acording to the location data that i get from different media. except for the temperature that was ok for me.
some of you tell me that the sensor may be broken beacuse the reading is around 1500 hPa, but the pressure value varies if I put it on an improvised vacuum pump.
I was tinking about the fact that I'm using an arduino Leonardo wich has 5v logic level.
I'm using that cheap sensor form ebay by the way
The absolute pressure reading seems OK to me (if this is actually the sensor pressure reading), normal atmospheric pressure at sea level is 1013.25 millibar or about 29.9 inch Hg. The sea-level pressure seems high, which could explain the wrong calculated elevation.
If that is the code you are using, then what it all the stuff about the "provided" pressure and altitude, you had earlier ?
If you took any altitude-sensing device to Denver or Johannesburg, and misled it into believing that it was at sealevel, then when you actually went to somewhere at sealevel, you would get a bogus answer.
The device is going to measure the actual pressure that it detects, which is converts to an altitude using a "standard" formula for the relationship between pressure and altitude.
The problem is, the atmospheric pressure varies because of the weather and other things, and there are various ways to "adjust" for this. Sometimes the adjustment scheme is more confusing than it really needs to be.
thanks for that. It is a surprise to me that it would be the source of the problem for some!
I don't know how many different Arduino compiler versions I've run the code on. And from the hardware side UNO's and Pro minis.... The results always corresponded with the data sheet.
Would this have to do with the Leonardo? What is your setup?
It also shows me from now on to tell people with such or similar problems to use the data sheet variables to confirm the calculations.
I wanted to use your code rather than the Adafruit library for 2 reasons really:
1: I have very little codespace left
2: Just "throwing another library at a problem" leaves little to learning
And did I get some learning done last night
Considering C and all it's variants are new to me (why did my university insist on Pascal?) - at least the strong background on type casting helped - I have been working hard on both the hardware and software aspects on my current project - hence using the arduino platform to speed things up rather than my usual route of rolling my own. Makes it easier knowing it is less likely to be a hardware issue...
Anyway, back on topic, the environment I have in place is:
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)
I was getting 1480 - 1508 mbar readings (was actually 1008 compared to my weather station) until I fixed the casting. Once casting fixed - bingo - spot on.
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
I have the same sensor and i used a bi-directional logic level converter for it to work. Also, the code i tested it with had altitude input, for a more exact pressure output.
I think you used same code when you got those high readings. Now I don't know if you can use it on 5 v logic level and get valid readings..
The code you tested it with would be the Adafruit Unified library. Dig inside the codebase, and you will find the exact same compenstation logic - taken from the same datasheet sample.
Once you dig in there - Adafruit also cast everything correctly, INCLUDING this example.
As mentioned, the issue appears to be how the compiler/environment handles default casting, if you leave it to the compiler to handle it (bad) you will get an unpredictable result based on how the author of your environment feels on the day. Isn't it better to strictly cast it anyway (good) to ensure you get it in the format you desire regardless? There is no overhead, and at best someone reading your code will also understand what is going on.
I should have mentioned all my i2c is at 3v3, although it is often mentioned that the BMP180 technically 5v tolerant on SDA and SCL - although the datasheet never points it out as the I2C specs are external to the device itself and another kettle of fish - it is about an ability to "drive" a voltage above a threshold cleanly without reflection/ringing (hence the termination resistors) and starts to enter the realm of throw stuff at it and see black magic once lines get long and more devices get added
Can we please STOP trying to tell me what it isn't in this case? it is not hardware or voltage. I am not a newbie to electronics or to code, just to the arduino environment (and c - c++) - which I am hopping into just because of the flood of cheap dev boards from china...Cheaper than I can get bare ATMegas for these days... I am happy to be wrong, but not happy to have the conversation derailed.
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.