I updated the IntersemaBaro.h library to include a method for printing the temperature. Still no luck on the altimeter yet, but admittedly I have not tried much !
I'm quite new to all this and I can get the altitude from the MS5607 on the serial monitor of my Arduino Uno.
But I'm not interested in the altitude, I'll get that from the GPS.
I want to know the pressure and temperature that the sensor is measuring.
Can you help me out with that?
In addition to pressure and temperature, is there any handy code out there for calculating air density?
The wikipedia page has some handy equations, but is there anything already coded up to do this? From the page, it looks like you need to measure humidity as well, and the "partial" air/water pressure.
I'm quite new to all this and I can get the altitude from the MS5607 on the serial monitor of my Arduino Uno.
But I'm not interested in the altitude, I'll get that from the GPS.
I want to know the pressure and temperature that the sensor is measuring.
Can you help me out with that?
How to get sea level pressure (SLP) at your location. Find the nearest airport and it's identifier for example KLAX = Los Angeles. Look it up here - http://www.aviationweather.gov/adds/metars/ you can switch to 'translated' weather by the search box to make reading easier. The drop down box should be set to past 1 hour. Hit Submit. If you're between two airports, put them both in and interpolate.
Thanks for your reply.
I have been struggling with this code for a few days now. The temperature looks good now.
What worrying me most is the calculation for the absolute pressure.
I can't get that done and return proper values.
In the documentation (the two pdfs on the product page) there are a few different ways to calculate the air pressure.
For your information: this project is going to be launched with a High Altitude Balloon so the values will get very close to the lower limits (-40°C / 10 mbar) of the sensor.
Altitude will not be calculated with this module. I'll use a GPS to report position and altitude data.
New to the forum and relatively new to arduino's. I'm in the process of building an integrated weather station. I have all the pieces worked out except the new ms5607 I received today. I have it setup on the mega by itself for testing and coding before i integrate it to entire station. I've hooked it up i2c and i'm getting -data using the library and sample code on the parallax site. Anyone have any luck with a new library? I am interested in really collecting barometric data for trends of weather current readings and has it been rising or falling. I'm not opposed to using the spi interface either if someone out there is having and luck in that direction.
No, it's correct. The KickStart uses the FullDuplexSerial object, for consistency with other examples. The object name pst is used out of convenience if someone wants to use the KickStart code as a springboard, and that "pst" is also the initials of the name of the serial terminal program people use to view the data.
Look at the call to the start routine, though. That's a PST call, not an FDS call. The latter requires four parameters. The example given would not even compile.
Ah, yes, you're right. There was a drive to update the code to be more consistent with the serial objects (even so three different ones are used in the 12 KickStart examples), but I'm surprised this one got changed but not rechecked. In any case, I did a quick compile verification, and the page and download have been corrected. Thanks for the catch.
The code has a flag for switching between the MS5607 and the MS5611 modules, but as far as I can tell they are physically, electrically, and programmatically compatible. Is this correct? The only difference that I can spot is that the MS5611 has a resolution double that of the MS5607
No, the math formulae for converting raw readings to pressure and altitude are different for the two chips. From a hardware interface standpoint, however, they're compatible.
I'm implementing this chip on a IOIO board interfaced with an Android phone. I2C is handled in the libraries, so I don't really have to worry about bits and such. I've been piecing things together from the datasheet and the example code, but it's rough going. Maybe some of you guys with more experience will be able to answer these questions:
1. What's the address? Is it 0x77 or 0x76
2. You send it a command to read a C value, and it returns two bytes, right? What are the commands? 0xA6 for C3, right?
3. You send it a command to start a conversion, then after some time you can read d1 and d2 by sending 0x00, right?
I'm not sure if I'm on the right track, but this is how I understand the datasheet. Once I get the values the conversions are trivial (you know...lots of memory, 1.2Ghz chip), but I'm new to i2c and a bunch of things could be wrong, I just want to make sure it's not my commands.
I'm implementing this chip on a IOIO board interfaced with an Android phone. I2C is handled in the libraries, so I don't really have to worry about bits and such. I've been piecing things together from the datasheet and the example code, but it's rough going. Maybe some of you guys with more experience will be able to answer these questions:
1. What's the address? Is it 0x77 or 0x76
2. You send it a command to read a C value, and it returns two bytes, right? What are the commands? 0xA6 for C3, right?
3. You send it a command to start a conversion, then after some time you can read d1 and d2 by sending 0x00, right?
I'm not sure if I'm on the right track, but this is how I understand the datasheet. Once I get the values the conversions are trivial (you know...lots of memory, 1.2Ghz chip), but I'm new to i2c and a bunch of things could be wrong, I just want to make sure it's not my commands.
1. 0x76
2. What do you mean by a "C value"? Do you mean a PROM value? In that case, you send a command (the PROM address index) to the device, then you received two bytes.*
3. Yes to the first part, no to the second. The conversion is for either d1 or d2: the device has only one ADC, so you have to pick which one you want to convert. The "Convert XX" type commands are what you send to begin the conversion. The 0x00 command is what you use to read the ADC measured value.*
*The MS5607 uses an I2C byte sequence to be careful of. It's seems to be non-standard in comparison to the "normal" way of using I2C devices (start+device+register). If your I2C library has something like this
result = i2c_obj.read(device_addr, register_addr)
Then you'll probably have a hard time accessing the MS5607. A careful look at the datasheet reveals that the MS5607 doesn't follow the register type of access: after the address byte, you either write one byte or read two/three bytes (as opposed to write device address, write register address, then read/write byte(s)).
If this doesn't help, you should start a new thread in the sensors forum with your specific questions.
A couple of weeks ago, I ordered one of the barometer modules along with the Propellar BOE board and was very pleasantly surprised when it worked exactly as it was supposed to. The sensitivity of this module is incredible as I was clearly able to see a reproducible pressure difference between putting the board on the floor compared to holding it over my head. The Spin code is an excellent starting point for me to also dump out the temperature.
Until I read this forum, I had no idea that the barometer module could work with the Basic Stamp - have one which has been gathering dust for a few years and it would be a great use for what I had assumed was a now underpowered processor.
The first thing I did, once I had the Propellar/Barometer module working was to dump out the data to my laptop and store it to disk. It was very nice to see the marked drop in pressure that occurred here today coincidental with a fairly large dump of snow. I'll need a few more of the modules as one will become part of my ad-hoc weather station that currently uses a much less sensitive Phidget pressure sensor as a barometer. It was challenging to deal with the high output rate of the serial port in VB6, but I've thrown together a program which averages the 12-15 readings every second and dumps them to a file which has timestamped pressure readings at 1/second. This is in csv format so it can be readily displayed with DPlot.
Being new to this forum, I haven't figured out yet how one posts code, but I'll be happy to share the VB6 pressure logging program with anyone who wants to use it.
It was with some trepidation that I bought the Propellar BOE as I haven't had much luck in my previous forays into Propellar programming, but I was very impressed how easy it was to interface the barometer module and have an immediately useful system.
Guess I should have just looked further down the page as I now realize I can post attachments to go along with a post.
I bought this device as part of a project I'm working on. I have been trying to get it to interface with an MSP430 via I2C.
I've been having troubles for a while now, but I think I have the issue isolated:
Once the MWP430 sends the start bit and address sequence, the barometer holds SDA low, effectively stalling the entire I2C bus.
PS is tied high, CS is low, SDA and SCL are each tied to the MSP430's VCC (3.5V) via 3k resistors.
I bought this device as part of a project I'm working on. I have been trying to get it to interface with an MSP430 via I2C.
I've been having troubles for a while now, but I think I have the issue isolated:
Once the MWP430 sends the start bit and address sequence, the barometer holds SDA low, effectively stalling the entire I2C bus.
PS is tied high, CS is low, SDA and SCL are each tied to the MSP430's VCC (3.5V) via 3k resistors.
Has anyone else experienced this problem?
Look at the i2c in the datasheet. It doesn't use a register address format like most devices. Ms5607 is odd in it's i2c specs.
SRLM, thanks for the response. As far as the address and commands are concerned, I am using the hex values found in the datasheet. I've taken the CS pin into account as well (the complement to the LSB in the address). What I'm finding is that the altimeter will stall the whole I2C bus after the address is sent. It seems like the device should either ACK (right address) or NACK (wrong address) at that point, but instead, it seems to just get stuck.
As an update, I'm finding that the problem is a bug which is briefly mentioned in the datasheet.
The reset can be sent at any time. In the event that there is not a successful power on reset this may be caused by the SDA being blocked by the module in the acknowledge state. The only way to get the MS5607-02BA to function is to send several SCLKs followed by a reset sequence or to repeat power on reset.
I'm not quite sure how to generate "several SCLKs" followed by the reset short of manually writing an I2C interface on the MSP430. The MSP430's builtin I2C module doesn't allow for sending a byte unless the address was successfully sent.
I tried to "repeat power on reset" to no avail. It seems that every time the altimeter turns on, it's coming across this odd ACK problem.
Does anyone have any suggestions on how to skirt this problem? Has anyone else run into this problem and found a solution?
Notice that it doesn't have the register address byte. The ellipses (...) can be either a "command" such as begin conversion or read PROM (command from Master), or it can be data (from Slave).
Of course, an I2C driver written for the first type (the "standard" I2C) wouldn't work with the MS5607. That's where the flexibility of the Propeller is nice. Still, it might be possible to work with the MSP430.
You might be able to send several SCLKs by manually toggling the IO pin. If you can't toggle the pin directly, then you could connect another IO pin to the SCLK pin and toggle that pin. Just be sure to set it to high impedance after that's done so it doesn't affect the bus.
One thing that you might try is to "ping" the device. You can do this by sending the following:
START / DEVICE BYTE +ACK / STOP
If the MS5607 is ready to respond, then it will respond with an ACK. Otherwise, you'll get NACK. You could try the routine with other I2C devices as well.
As far as this specific issue: I've never had the MS5607 lock up on me.
Hi I'm relatively new to BS2, but I am implementing the 5607 Altimeter as a test project, and running into some issues. I am hoping someone might provide some ideas - hopefully these questions aren't too basic. I'm using a BS2 with SPI. I used the demo file that Tracy Allen posted awhile back (2011), and used the same wiring setup. What I am seeing is after the reset command, when I query for the coefficients using SHIFTIN/SHIFTOUT commands, it returns bogus data. Based on this thread, I tried adding a pulldown resistor from SDO to ground, and while that is in place, the coefficents all return a value of 0 (16 bits all 0). When I remove the pulldown, it returns 16 bits all set to 1. It does this regardless of which coefficient I query for. My suspicion is that I must have something wired incorrectly, but I'm hoping someone can give some troubleshooting ideas. Any thoughts/ideas would be apppreciated. Note: I am new to using SPI but have read quite of bit of the docs so I generally understand how it works. I did confirm my code does pull the PS pin low at the start to ensure it is set to SPI mode.
The issue with the pulldown resistor turned out to be bogus, confined to only one sample '5607.
Are you using the Parallax 29124 module that has the level shifters?
One common mistake is to reverse the sdi and sdo pins. The module sdo pin has to connect to the Stamp pin that does SHIFTIN, and the module sdi/sda pin has to connect to the Stamp pin that does SHIFTOUT.
Yes, this is the 29124 module, I just ordered it from Parallax this week. I doublechecked my SHIFTIN is going to the SDO, and SHIFTOUT going to SDI.
I'll attach a photo of my board and my code (which is a trimmed down version of yours that only tries to retrieve the coefficients), if you'd like to look at those. I've removed the resistor so now I see the return value as 16 bits of 1.
I don't see anything wrong with your wiring, and when I run your program, I get reasonable results.
I added the bit to display in decimal as well as binary. I'd say, check that all the pins are making good contact with the protoboard. Sometimes there will be a weak spring. Also you might try adding a 0.1µF capacitor between the GND and Vin pins right at the '5607 module. The fallback solution for you in particular is a quick trip up the road to Parallax, rockin' Rocklin!
Comments
Altimeter_Arduino_10_v2.zip
Cheers,
-Joe
-Joe
http://www.highaltitudescience.com/
I'm quite new to all this and I can get the altitude from the MS5607 on the serial monitor of my Arduino Uno.
But I'm not interested in the altitude, I'll get that from the GPS.
I want to know the pressure and temperature that the sensor is measuring.
Can you help me out with that?
The wikipedia page has some handy equations, but is there anything already coded up to do this? From the page, it looks like you need to measure humidity as well, and the "partial" air/water pressure.
Hey Elmar - if you download the code above http://forums.parallax.com/attachment.php?attachmentid=88986&d=1327669841 you can use:
int temp = baro.getTemperature();
Serial.print("Temperature: ");
Serial.println(temp);
To display the temperature.
-Joe
How to get sea level pressure (SLP) at your location. Find the nearest airport and it's identifier for example KLAX = Los Angeles. Look it up here - http://www.aviationweather.gov/adds/metars/ you can switch to 'translated' weather by the search box to make reading easier. The drop down box should be set to past 1 hour. Hit Submit. If you're between two airports, put them both in and interpolate.
Thanks for your reply.
I have been struggling with this code for a few days now. The temperature looks good now.
What worrying me most is the calculation for the absolute pressure.
I can't get that done and return proper values.
In the documentation (the two pdfs on the product page) there are a few different ways to calculate the air pressure.
For your information: this project is going to be launched with a High Altitude Balloon so the values will get very close to the lower limits (-40°C / 10 mbar) of the sensor.
Altitude will not be calculated with this module. I'll use a GPS to report position and altitude data.
Elmar
New to the forum and relatively new to arduino's. I'm in the process of building an integrated weather station. I have all the pieces worked out except the new ms5607 I received today. I have it setup on the mega by itself for testing and coding before i integrate it to entire station. I've hooked it up i2c and i'm getting -data using the library and sample code on the parallax site. Anyone have any luck with a new library? I am interested in really collecting barometric data for trends of weather current readings and has it been rising or falling. I'm not opposed to using the spi interface either if someone out there is having and luck in that direction.
https://sites.google.com/site/parallaxinretailstores/home/altimeter-module-ms5607
The code is wrong?
OBJ
pst : "FullDuplexSerial"
alt : "29124_altimeter"
Should be:
OBJ
pst : "parallax serial terminal"
alt : "29124_altimeter"
I think both the downloaded code and the code on the site were wrong?
Addie
Addie, you're quite right. Thanks for pointing it out!
-Phil
-- Gordon
Look at the call to the start routine, though. That's a PST call, not an FDS call. The latter requires four parameters. The example given would not even compile.
-Phil
-- Gordon
http://www.meas-spec.com/downloads/MS5611-01BA03.pdf
http://www.parallax.com/portals/0/downloads/docs/prod/sens/29124-AltimeterDatasheet.pdf
If that's the case, then it seems like upgrading the altimeter modules to the MS5611 would be an easy way to double the resolution.
-Phil
1. What's the address? Is it 0x77 or 0x76
2. You send it a command to read a C value, and it returns two bytes, right? What are the commands? 0xA6 for C3, right?
3. You send it a command to start a conversion, then after some time you can read d1 and d2 by sending 0x00, right?
I'm not sure if I'm on the right track, but this is how I understand the datasheet. Once I get the values the conversions are trivial (you know...lots of memory, 1.2Ghz chip), but I'm new to i2c and a bunch of things could be wrong, I just want to make sure it's not my commands.
1. 0x76
2. What do you mean by a "C value"? Do you mean a PROM value? In that case, you send a command (the PROM address index) to the device, then you received two bytes.*
3. Yes to the first part, no to the second. The conversion is for either d1 or d2: the device has only one ADC, so you have to pick which one you want to convert. The "Convert XX" type commands are what you send to begin the conversion. The 0x00 command is what you use to read the ADC measured value.*
*The MS5607 uses an I2C byte sequence to be careful of. It's seems to be non-standard in comparison to the "normal" way of using I2C devices (start+device+register). If your I2C library has something like this Then you'll probably have a hard time accessing the MS5607. A careful look at the datasheet reveals that the MS5607 doesn't follow the register type of access: after the address byte, you either write one byte or read two/three bytes (as opposed to write device address, write register address, then read/write byte(s)).
If this doesn't help, you should start a new thread in the sensors forum with your specific questions.
Until I read this forum, I had no idea that the barometer module could work with the Basic Stamp - have one which has been gathering dust for a few years and it would be a great use for what I had assumed was a now underpowered processor.
The first thing I did, once I had the Propellar/Barometer module working was to dump out the data to my laptop and store it to disk. It was very nice to see the marked drop in pressure that occurred here today coincidental with a fairly large dump of snow. I'll need a few more of the modules as one will become part of my ad-hoc weather station that currently uses a much less sensitive Phidget pressure sensor as a barometer. It was challenging to deal with the high output rate of the serial port in VB6, but I've thrown together a program which averages the 12-15 readings every second and dumps them to a file which has timestamped pressure readings at 1/second. This is in csv format so it can be readily displayed with DPlot.
Being new to this forum, I haven't figured out yet how one posts code, but I'll be happy to share the VB6 pressure logging program with anyone who wants to use it.
It was with some trepidation that I bought the Propellar BOE as I haven't had much luck in my previous forays into Propellar programming, but I was very impressed how easy it was to interface the barometer module and have an immediately useful system.
Guess I should have just looked further down the page as I now realize I can post attachments to go along with a post.
I've been having troubles for a while now, but I think I have the issue isolated:
Once the MWP430 sends the start bit and address sequence, the barometer holds SDA low, effectively stalling the entire I2C bus.
PS is tied high, CS is low, SDA and SCL are each tied to the MSP430's VCC (3.5V) via 3k resistors.
Has anyone else experienced this problem?
Look at the i2c in the datasheet. It doesn't use a register address format like most devices. Ms5607 is odd in it's i2c specs.
I'm not quite sure how to generate "several SCLKs" followed by the reset short of manually writing an I2C interface on the MSP430. The MSP430's builtin I2C module doesn't allow for sending a byte unless the address was successfully sent.
I tried to "repeat power on reset" to no avail. It seems that every time the altimeter turns on, it's coming across this odd ACK problem.
Does anyone have any suggestions on how to skirt this problem? Has anyone else run into this problem and found a solution?
Using the MS5607, I've noticed that it deviates from the "standard" I2C format. Most I2C devices use something like this:
The MS5607 (and 5611) use:
Notice that it doesn't have the register address byte. The ellipses (...) can be either a "command" such as begin conversion or read PROM (command from Master), or it can be data (from Slave).
Of course, an I2C driver written for the first type (the "standard" I2C) wouldn't work with the MS5607. That's where the flexibility of the Propeller is nice. Still, it might be possible to work with the MSP430.
You might be able to send several SCLKs by manually toggling the IO pin. If you can't toggle the pin directly, then you could connect another IO pin to the SCLK pin and toggle that pin. Just be sure to set it to high impedance after that's done so it doesn't affect the bus.
One thing that you might try is to "ping" the device. You can do this by sending the following:
If the MS5607 is ready to respond, then it will respond with an ACK. Otherwise, you'll get NACK. You could try the routine with other I2C devices as well.
As far as this specific issue: I've never had the MS5607 lock up on me.
Are you using the Parallax 29124 module that has the level shifters?
One common mistake is to reverse the sdi and sdo pins. The module sdo pin has to connect to the Stamp pin that does SHIFTIN, and the module sdi/sda pin has to connect to the Stamp pin that does SHIFTOUT.
Yes, this is the 29124 module, I just ordered it from Parallax this week. I doublechecked my SHIFTIN is going to the SDO, and SHIFTOUT going to SDI.
I'll attach a photo of my board and my code (which is a trimmed down version of yours that only tries to retrieve the coefficients), if you'd like to look at those. I've removed the resistor so now I see the return value as 16 bits of 1.
Any thoughts appreciated...
I don't see anything wrong with your wiring, and when I run your program, I get reasonable results.
I added the bit to display in decimal as well as binary. I'd say, check that all the pins are making good contact with the protoboard. Sometimes there will be a weak spring. Also you might try adding a 0.1µF capacitor between the GND and Vin pins right at the '5607 module. The fallback solution for you in particular is a quick trip up the road to Parallax, rockin' Rocklin!