Nevermind. I just read the "Light Sensitive" label.
It's now reading
21.82 degrees
964.72 mbar
and no message.
If I convert the pressure to inches of mercury I get 28.49. The local airport is showing 29.67.
What could cause that big of a difference? I checked other weather underground stations around me and all were close to the 29.67.
Published pressure readings are corrected to sea level. If you are substantially above seal level, and without a similar correction (which Tracy mentioned above), you will get a lower pressure value than the published readings.
Great work, Tracy! I'm amazed you were able to shoehorn all of that into a Stamp!
Luckily for my project pressure is all that is important so I won't have to adjust the number further. I'm moving a servo motor slightly as the pressure changes.
Thanks Phil! It took a lot of playing around in Excel to rearrange the terms in a way that could take advantage of a double precision version of the ** operator and avoid computations involving triple or quad precision as outlined in the data sheet algorithm.
abmcdan, Thanks for the feedback. I am looking for any issues like the one you posed, and wonder if altitude explanation is enough to explain your discrepancy. I am located at near sea level, and my current reading (1021.82mb = 30.18" Hg uncorrected) is quite close to my nearest airport (OAK 30.23" Hg)
I'm a beginner with this stuff and trying to learn as much as possible.. why do you cross the SDO to the ground? I went straight to P7 with a resistor inbetween and it worked.
What resistor did you use? For me it did not work at all without that 4.7kΩ resistor there, between sdo and ground. The output of the barometer acted as if it were and open collector that needed the pulldown. I have only one of these boards, and it was a pre-release version, so it may be different in that respect. If you look at the photo that I posted, it looks like the sdo pin is connected to the collector of a transistor on the blue circuit board, and maybe to a resistor. I'll check it again when I have a chance.
I think I figured out the problem with the SDO pin, why I needed a pulldown resistor and you didn't. The barometer chip itself is running from a 2.5V power supply, and there is a standard circuit on the SDO output that translates from 2.5V to 5V for the Stamp, using a BSS123 n-mosfet. The Stamp side has a 4.7kΩ pullup resistor to 5V, but that requires that the transistor sink 1 milliamp when low. But that is on the far edge of what the BS123 can sink when it has 2.5V on its gate. In a random sampling some will be able to do it and some not.
I replaced the 4.7kΩ pullup with 20kΩ, and now all is well, my 29124 works fine without the pulldown hack. I'll bring this issue to the attention of Parallax.
I bought the MS5607 module today but am struggling with the programming. I have an Arduino and, based on searches today, I can't find any code (sketches) for interacting with this device. I'm fairly new to Arduino and I2C, which is certainly a part of the problem.
If anyone comes across a link of on Arduinos interfacing with this altimeter, I would really appreciate it.
Thanks, this is a great start. I had initially avoided it as the library looked to be written for a different device. Now, I'm getting a good stream of data from the sensor. Next job will be to make some sense of it. Should be a good Sunday project...
I updated the BASIC Stamp code for the #29124 attached to post #30. It now includes the 2nd order compensation for "low" temperatures, low in quotes because in the MS5607 data sheet it kicks in at 20 degrees Celsius. Below 20 it includes a term proportional to the square of temperature. At zero degrees the correction amounts to about 3 millibar.
Unlike the first order coefficients, which are tested at the MSI factory and stored in the eeprom of each individual barometer, the second order algorithm is generic. I placed my sensor in a freezer, and the pressure reading without the second order compensation went up 3 mb, but with 2nd order compensation it went down 1 mb, so I think in this case it was a bit overcompensated. But having the squared term allows that to be adjusted for best results in individual calibration if need be.
The photo attached to post #30 is now minus the klugy pulldown resistor I had initially on the SDO pin. Kevin Cook is sending me a couple more of the production #19124 and I'll be looking more at the issue of SDO signal swing. Note that this issue applies only to the SPI mode. That pin is not used in I2C mode.
None of them had the issue with the SDO pin that I had experienced with the preproduction unit, where as it turned out, the transistor that translates from 2.5V to 5V was too weak to pull down all the way to zero. Here is are 'scope traces from unit #1 to show what I mean. The first picture, lower trace with 1V/division, is the SDO output with the standard 4.7kΩ pullup resistor. It drops down from 5V to 2.5V. The upper trace is CS-chip select. Second picture, lower trace, same scale, is the proper signal that goes all the way from 5V down to zero. The improper signal did not cross the Stamp's input threshold at 1.4V and therefore was not recognized. My conclusion is that the problem I experienced was an anomaly and there was just something out of whack with that first unit, or I somehow released a half-fatal dose of magic smoke from the transistor.
Thanks, this is a great start. I had initially avoided it as the library looked to be written for a different device. Now, I'm getting a good stream of data from the sensor. Next job will be to make some sense of it. Should be a good Sunday project...
I am a total newb with Arduino so maybe I am missing something obvious.... probably.
I attached an updated IntersemaBaro.h IntersemaBaro-1.0.zip that uses the new format for Arduino 1.0 if anyone else has thoughts.
-Joe
Agreed, I'm having the same problem with 1.0. For some reason, when I went back to ver 23, I'm still having problems with the library. I'm fairly new as well, but intend to spend some quality time with it this weekend. Overall, I've not been happy with the 5607 for Arduino as I've never had good quality data. My perception is that there are few people interfacing the 5607 with the Arduino, resulting in a lack of on-going library development.
This weekend, I intend to spend some quality time with the library to see if I can debug it.
Agreed, I'm having the same problem with 1.0. For some reason, when I went back to ver 23, I'm still having problems with the library. I'm fairly new as well, but intend to spend some quality time with it this weekend. Overall, I've not been happy with the 5607 for Arduino as I've never had good quality data. My perception is that there are few people interfacing the 5607 with the Arduino, resulting in a lack of on-going library development.
This weekend, I intend to spend some quality time with the library to see if I can debug it.
Good luck,
Bill
Hey guys!
I'm new here on the Parallax forum, but have been playing with the 5607 today. I did have to go back to ver 23, as you had stated, and didn't have any problems. Here are the 2 files I'm using (make sure they're in the same directory as the KickStart website says). I only made a few minor adjustments to the .pde file to have the LED flash and added a little text to the serial output. I added a few bits of debugging to the .h file, I started poking around in there and found #ifdef DEBUG in a few places, so I uncommented a few serial commands and wrapped them in the same. To see the additional debugging information, add #define DEBUG somewhere at the top of the file.
Good work, Joe. I just went through and rewrote the library separately and it compiles fine. Unfortunately, I don't have my Arduino at hand but, by tomorrow morning, I expect to have the whole project humming along. If mine revised file doesn't work, I'll try yours next. My guess is that our end results are very similar.
My next project is to slim down the library so that it takes less space...
I was able to read the raw temperature, pressure, and altitude, but all 3 were erratic. The temperature started out looking good, so I coded the Celsius to Fahrenheit conversion on the Arduino, but after a while it would fluctuate between -20 F and 90 F. The altitude of the local airport (less than 5 miles from me) is 30 meters above sea level. The raw altitude was coming back as -29598 (and staying steady, but unless I need to multiply by -1, this is wrong). The pressure was all over the place as well, making huge jumps up and down.
Has anyone experienced this with the sensor? Any ideas on what could be wrong? Am I reading the values too quick maybe? I even changed the averaging to take 8 samples instead of 4 to see if it leveled out, but it didn't make a difference.
OK, now I'm mystified. I downloaded and installed your new Arduino library (thanks for the effort). I also used a simple sketch, in order to test the device. I rechecked my wiring and it appears OK, the sketch and libraries compile fine, and I verified 5v is going to the altimeter. SCL is wired to A5 and SDA is wired to A4.
It suggests that I'm at -51 feet (actual is about +200 feet). Then, when I carry it downstairs, it suggests that I've descended 3 feet (instead ~9 feet).
Two questions for those who have had success:
1. Do I need pull-up resistors on SCL and SDA? I had thought that this was already set up within the Uno. If I need to pull them up, I would presume to reference http://www.dsscircuits.com/articles/effects-of-varying-i2c-pull-up-resistors.html
2. Why the bizarre results? This seems to be too big of an error to account for in barometric pressure (particularly given that it is not accurately measuring relative elevation change). This suggests that there must be some correction formula for both relative and absolute elevation (such as a constant multiplier and an additive correction for barometric pressure).
The external pull-ups are usually not *required* as the Arduino is fairly tolerant as long as the cable length is short, but you can always add them if you'd prefer. The Arduino doesn't have them internally. Not having the pull-ups is unlikely to cause data errors. The I2C comm usually won't connect or you'll get wildly wrong data. The altimeter docs say there's already a pull-up across the SDA line, so you may need to experiment to see what works best.
How is your conversion to feet working? I usually use feet = cm / 30.48.
The IntersemaBaro.h file that does the actual work is someone's adaptation of another contributor's Arduino IMU project. I found the original project, and am in the process of trying to see what changes were made, and why. I wouldn't put 100% faith in that library, but it should be helpful in getting things started. In any case, I don't think it's doing the compensation that the full Propeller example is doing. So, at best, it's use is for reading changes in relative altitude (when temperature isn't a consideration), and not absolute altitude.
The pressure was all over the place as well, making huge jumps up and down.
This sounds like you're getting garbage back from the sensor. In this case, I'd try adding those pull ups on the SDA and SCL lines. Try 1.8k to 3.3k to start. Also try Arduino to sensor connecting wires of <6".
But now back home, it is showing me as 164' below sea level... which is wrong.
Ar you correcting your altitude for the current sea-level air pressure? If you don't, you could easily get the kind of readings you observe if the atmospheric pressure is high.
The Arduino library provided for the sensor on the Kickstart site has no provision for compensating for current sea-level air pressure. This is why that demonstration is best for relative altitude change, and over a limited height of say, under 1,000 feet. It doesn't come anywhere near the insane amount of math involved in the Propeller library.
The IntersemaBaro.h library is reading both pressure and temperature from the sensor. You can look at the code to see what they're doing. What the library lacks is a way to calibrate the sensor to current sea-level pressure. I imagine it could be adapted to do that. Whether or not you need it give you absolute altitude would depend on your application. A rocketry application, for example, is mostly interested in how it the thing flew from the ground.
I've not yet worked out the math they're using in the ConvertPressureTemperature() function, but that's where all the temperature/pressure conversions are taking place. Note that there are lots of commented-out Serial.print debugging sections. Uncommenting some of those ought to provide some insight.
-- Gordon
PS: I snagged the 1.0 library you posted for the KickStart wiki, BTW. Saved me from having to do it!
Comments
It's now reading
21.82 degrees
964.72 mbar
and no message.
If I convert the pressure to inches of mercury I get 28.49. The local airport is showing 29.67.
What could cause that big of a difference? I checked other weather underground stations around me and all were close to the 29.67.
Thanks for all your help
Great work, Tracy! I'm amazed you were able to shoehorn all of that into a Stamp!
-Phil
Luckily for my project pressure is all that is important so I won't have to adjust the number further. I'm moving a servo motor slightly as the pressure changes.
abmcdan, Thanks for the feedback. I am looking for any issues like the one you posed, and wonder if altitude explanation is enough to explain your discrepancy. I am located at near sea level, and my current reading (1021.82mb = 30.18" Hg uncorrected) is quite close to my nearest airport (OAK 30.23" Hg)
My reading: 28.49 inches of mercury
Airport: 29.67 inches of mercury
Airport Altitude: 1135 ft
Hope this helps.
www.novalynx.com/manuals/bp-elevation-correction-tables.pdf
Find your altitude on the chart, then add the deviation from zero to your pressure reading to get the adjusted reading.
-Phil
I really appreciate all your help.
I'm a beginner with this stuff and trying to learn as much as possible.. why do you cross the SDO to the ground? I went straight to P7 with a resistor inbetween and it worked.
I replaced the 4.7kΩ pullup with 20kΩ, and now all is well, my 29124 works fine without the pulldown hack. I'll bring this issue to the attention of Parallax.
If anyone comes across a link of on Arduinos interfacing with this altimeter, I would really appreciate it.
It looks like there's some Arduino code there.
-Phil
Thanks, this is a great start. I had initially avoided it as the library looked to be written for a different device. Now, I'm getting a good stream of data from the sensor. Next job will be to make some sense of it. Should be a good Sunday project...
Again, I appreciate the help.
Unlike the first order coefficients, which are tested at the MSI factory and stored in the eeprom of each individual barometer, the second order algorithm is generic. I placed my sensor in a freezer, and the pressure reading without the second order compensation went up 3 mb, but with 2nd order compensation it went down 1 mb, so I think in this case it was a bit overcompensated. But having the squared term allows that to be adjusted for best results in individual calibration if need be.
The photo attached to post #30 is now minus the klugy pulldown resistor I had initially on the SDO pin. Kevin Cook is sending me a couple more of the production #19124 and I'll be looking more at the issue of SDO signal swing. Note that this issue applies only to the SPI mode. That pin is not used in I2C mode.
None of them had the issue with the SDO pin that I had experienced with the preproduction unit, where as it turned out, the transistor that translates from 2.5V to 5V was too weak to pull down all the way to zero. Here is are 'scope traces from unit #1 to show what I mean. The first picture, lower trace with 1V/division, is the SDO output with the standard 4.7kΩ pullup resistor. It drops down from 5V to 2.5V. The upper trace is CS-chip select. Second picture, lower trace, same scale, is the proper signal that goes all the way from 5V down to zero. The improper signal did not cross the Stamp's input threshold at 1.4V and therefore was not recognized. My conclusion is that the problem I experienced was an anomaly and there was just something out of whack with that first unit, or I somehow released a half-fatal dose of magic smoke from the transistor.
Hey Bill - I don't have an answer either, I started updating the libraries since what is on the kickstarter site is not compliant with Arduino 1.0 <http://blog.makezine.com/archive/2011/12/arduino-1-0-is-out-heres-what-you-need-to-know.html>. It is stuck on Wire.endTransmission(); in the ResetSensor method of IntersemaBaro.h.
I am a total newb with Arduino so maybe I am missing something obvious.... probably.
I attached an updated IntersemaBaro.h IntersemaBaro-1.0.zip that uses the new format for Arduino 1.0 if anyone else has thoughts.
-Joe
Agreed, I'm having the same problem with 1.0. For some reason, when I went back to ver 23, I'm still having problems with the library. I'm fairly new as well, but intend to spend some quality time with it this weekend. Overall, I've not been happy with the 5607 for Arduino as I've never had good quality data. My perception is that there are few people interfacing the 5607 with the Arduino, resulting in a lack of on-going library development.
This weekend, I intend to spend some quality time with the library to see if I can debug it.
Good luck,
Bill
Hey guys!
I'm new here on the Parallax forum, but have been playing with the 5607 today. I did have to go back to ver 23, as you had stated, and didn't have any problems. Here are the 2 files I'm using (make sure they're in the same directory as the KickStart website says). I only made a few minor adjustments to the .pde file to have the LED flash and added a little text to the serial output. I added a few bits of debugging to the .h file, I started poking around in there and found #ifdef DEBUG in a few places, so I uncommented a few serial commands and wrapped them in the same. To see the additional debugging information, add #define DEBUG somewhere at the top of the file.
I'll post again later as my tinkering continues.
Changing the sample code to 1.0 format as detailed in the makezine link above and then adding Wire.begin() to the reset method fixed it.
It is attached here:
IntersemaBaro-Arduino-1.0.zip
-Joe
My next project is to slim down the library so that it takes less space...
Bill
Has anyone experienced this with the sensor? Any ideas on what could be wrong? Am I reading the values too quick maybe? I even changed the averaging to take 8 samples instead of 4 to see if it leveled out, but it didn't make a difference.
OK, now I'm mystified. I downloaded and installed your new Arduino library (thanks for the effort). I also used a simple sketch, in order to test the device. I rechecked my wiring and it appears OK, the sketch and libraries compile fine, and I verified 5v is going to the altimeter. SCL is wired to A5 and SDA is wired to A4.
#include <Wire.h>
#include "IntersemaBaro.h"
Intersema::BaroPressure_MS5607B baro(true);
void setup() {
Serial.begin(9600);
Wire.begin();
baro.init();
}
void loop() {
const int altitude = baro.getHeightCentiMeters();
Serial.println((float)altitude/91.44); //converts to feet
}
It suggests that I'm at -51 feet (actual is about +200 feet). Then, when I carry it downstairs, it suggests that I've descended 3 feet (instead ~9 feet).
Two questions for those who have had success:
1. Do I need pull-up resistors on SCL and SDA? I had thought that this was already set up within the Uno. If I need to pull them up, I would presume to reference http://www.dsscircuits.com/articles/effects-of-varying-i2c-pull-up-resistors.html
2. Why the bizarre results? This seems to be too big of an error to account for in barometric pressure (particularly given that it is not accurately measuring relative elevation change). This suggests that there must be some correction formula for both relative and absolute elevation (such as a constant multiplier and an additive correction for barometric pressure).
As before, I appreciate the help...
Bill
How is your conversion to feet working? I usually use feet = cm / 30.48.
The IntersemaBaro.h file that does the actual work is someone's adaptation of another contributor's Arduino IMU project. I found the original project, and am in the process of trying to see what changes were made, and why. I wouldn't put 100% faith in that library, but it should be helpful in getting things started. In any case, I don't think it's doing the compensation that the full Propeller example is doing. So, at best, it's use is for reading changes in relative altitude (when temperature isn't a consideration), and not absolute altitude.
-- Gordon
This sounds like you're getting garbage back from the sensor. In this case, I'd try adding those pull ups on the SDA and SCL lines. Try 1.8k to 3.3k to start. Also try Arduino to sensor connecting wires of <6".
-- Gordon
Well now I feel like I spoke too soon. I wrote it and it was within acceptable error.
But now back home, it is showing me as 164' below sea level... which is wrong.
Hopefully we can team together and get this fixed.
-Joe
Ar you correcting your altitude for the current sea-level air pressure? If you don't, you could easily get the kind of readings you observe if the atmospheric pressure is high.
-Phil
-- Gordon
Has anyone gotten the temperature feature of the MS607 working with an Arduino?
Thanks,
-Joe
I've not yet worked out the math they're using in the ConvertPressureTemperature() function, but that's where all the temperature/pressure conversions are taking place. Note that there are lots of commented-out Serial.print debugging sections. Uncommenting some of those ought to provide some insight.
-- Gordon
PS: I snagged the 1.0 library you posted for the KickStart wiki, BTW. Saved me from having to do it!