Altimeter MS5607 Operating Specs (High Altitude Balloon)
aparis1983
Posts: 22
The operational temperature for this sensor is -40 to 185 degrees Farenheit. Has anyone tested these below the -40 threshold? I'm using this sensor on a high altitude balloon. From 30,000 feet and above its below -40 and can go as low as -70. I'm using this module mainly for altitude...temperature would have been a plus. My question is if I would still get a barometric reading at below the -40 threshold? Or is it only the thermometer that locks up?
I'm thinking I might need to keep the sensor well insulated inside the capsule but this would mean I would probably get a barometric reading with the slightly higher pressure inside the capsule.
Andrew
I'm thinking I might need to keep the sensor well insulated inside the capsule but this would mean I would probably get a barometric reading with the slightly higher pressure inside the capsule.
Andrew
Comments
We have sent this sensor up to about 105k feet. As I recall it stopped providing any useful data at about 60k feet on ascent, then started working again on descent at about the same altitude. I believe the baro pressure dropped below the specs for the sensor. I'll get the data files together for you tomorrow if you like - I haven't looked at since last summer.
The sensor itself is supposed to go down to 10mb (=100kPa). At altitude 60000 feet, the pressure should be around 70mb, within range. The response in both pressure and temperature becomes nonlinear at low temperatures, and there is second order correction that has to be applied in firmware. One correction below 20°C and another on top of that below -15°C. When I did a version for the BASIC Stamp, I did the <20°C correction but never got around to the lower temperature. I'm not sure if that would help, but it is something to consider.
P.S. The raw data shows the MS5607 recorded pressure down to 9 mb.
Any idea how to make these two corrections for temperatures below 20 celsius and -15 celsius for the code below? Currently, this code displays altitude and temperature on a serial LCD and logs this data in a Micro SD card.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 sd_DO = 22 sd_CLK = 23 sd_DI = 24 sd_CS = 25 TX_PIN = 2 BAUD = 19_200 START_ALT = 20 OBJ sdfat : "fsrw" pst : "Parallax Serial Terminal" LCD : "FullDuplexSerial.spin" alt : "29124_altimeter" PUB start | a , t , mount LCD.start(TX_PIN, TX_PIN, %1000, 19_200) waitcnt(clkfreq / 100 + cnt) mount := \sdfat.mount_explicit (sd_DO, sd_CLK, sd_DI, sd_CS) LCD.tx(17) if mount < 0 lcd.str( string( 13, "Failed to mount", 13 ) ) abort lcd.str(string( 13, "SD card found & mounted", 13) ) alt.start(alt#QUICKSTART, alt#BACKGROUND) alt.set_resolution(alt#HIGHEST) alt.set_altitude(alt.m_from_ft(START_ALT * 100)) sdfat.popen( string("Data.csv"),"w") repeat a := alt.altitude(alt.average_press) lcd.str(string("Alt:")) lcd.str(alt.formatn(a, alt#TO_FEET,8)) sdfat.popen( string("Data.csv"),"a") sdfat.pputs(alt.formatn(a, alt#TO_FEET,8)) lcd.str(string("Temp:")) lcd.str(alt.formatn(t, alt#TO_DEGF,8)) t := alt.current_temp sdfat.pputs(alt.formatn(t, alt#TO_DEGF,8)) sdfat.pputs(string(" ",13,10)) sdfat.pclose LCD.tx(13) waitcnt(clkfreq * 5 + cnt)So I launched the high altitude balloon last weekend, and I got some very interesting readings. I'm sure you'll recognize the pattern. It replicates your readings (in the altitude, temperature graph you uploaded) almost exactly. Just as with your readings I had a spike starting at roughly 20,000 meters all the way to 40,000 meters, back down to 20k, then a flat line at about 23,000 meters with another spike. It's in essence a mirror image of the same errors you got. I don't think arcing would explain the exact same behaviors in both our readings.
It was pretty warm in my capsule (never dropped below freezing). This was due to overzealous insulation (I added multiple layers of thermal blanketing both inside and outside). Unfortunately, it was so hot in the capsule that both GoPro cameras shut off due to overheating at around 10,000 feat. They're programmed to shut off at 60 celsius. Inside the capsule it reached 45 degrees, but I have no doubts the actual cameras may have easily reached 60.
What else do you think may be causing these crazy readings and the flatline?
Andres
Lev, I see your P.S. that the '5607 collected raw pressure data down to 9mb. Do you have a complete file of the raw pressure and temperature data to compare with the subsequent math?
That's a good idea to try running it with a fake starting altitude. However, I encountered something awkward. I set the starting altitude to 66,450 feet (the approximate altitude at which the first spike occurs), and the LCD displayed 6,960 feet. I tried various starting altitudes going all the way down to 6,960 with the same result every time. So the altitude is capped at 6,960 feet and works fine below this.
I tried to see if I would get the same results in meters (2,121 meters = 6,690 feet), and oddly enough it's capped at 646 meters instead. I have no explanation. Currently going through the sensor's documentation to see if I can find anything.
I'm using the exact same code that I submitted in me second to last post.
Andres
Do you get the same results on another Propeller set-up and what about other people?
This morning I also tested the 6,960 feet threshold by setting the starting altitude at 6,958 feet and seeing if I could get a reading above that by going up a flight of stairs. It does seem to work. So, at this point it looks like there's a cap of 6,960 feet for the starting altitude but can go above that after it's running. I'm a little more confused now.
Andres
Another thing to consider for the altitude readings is to look at the code for the altimeter and how it does the cubic interpolation to make sure the code isn't trying to access a value outside the index of the altitude table. I got the impression it might do that at very high altitudes... like the ones you might see on a high altitude balloon...
Can you send up multiple boards or add another sensor to your current board?
Here is code for using an SD card:
http://learn.parallax.com/propeller-c-simple-devices/sd-card-data
Here is how to use the Propeller's other cogs:
http://learn.parallax.com/multicore-approaches
The current setup is a parallax activity board, using SPI protocol and programmed in Propeller C. I am recording D1, D2, calculated temperature, and calculated pressure on an SD card. By recording D1 and D2, I can fully post-process the data and compare it to what I'm calculating on board. If you have any suggestions I would easily be able to incorporate in the next couple hours, I would be open to trying something...
That's great that you're recording D1 and D2 as well as the calculated values. That could help with the glitch that others have seen at high altitude. Maybe something in the calculation. Interesting thought about the cubic interpolation. It seems to me linear interpolation should be fine. Altitude vs pressure is not a wild curve, and it is squishy anyway.
intervalticks := clkfreq * 10 ' for ten second repeat time := cnt repeat waitcnt(time+=intervalticks) ' do somethingIt gets more complicated if the system has to switch clock frequency in mid-course, say, for power saving. I like to have a real time clock chip on board running on its own 32kHz xtal, so the time and date are always available.Are you running the altimeter as a background task? Phil's spin code allows the task to run either with a query or in the background with automous sampling and averaging. The filtered reading is very stable. Good for a barometer or for slow changes. For a balloon, I guess you'd want fast response.
The D1 and D2 values should be point-in-time, though, to probe the accuracy of the algorithm, and the pressure and temperature should be calculated at each point in time too. A 5th and 6th field could be added for averaged values.
Parallax sells the DS1302 Real-Time-Clock (RTC) along with the 32 kHz crystal that Tracy mentioned.
http://www.parallax.com/product/604-00005
http://www.parallax.com/product/251-03230
Spin Code
http://obex.parallax.com/object/14
This might be useful - Altimeter with RTC to an LCD
http://obex.parallax.com/object/608
There are other versions of this chip such as the DS1307 which uses I2C and is used on the Propeller Professional Development Board.
@Tracy: The learning library has a relative timing routine that will return elapsed time. As long as we record the initial time, the relative time will give us the absolute time to compare with our GPS sensor. The code runs the altimeter autonomously and records single data points at 5-sec intervals along with elapsed time from the start. I wrote filtering into the code, but it's commented out because I couldn't think of a good implementation that would still record the raw values without a ballooning data file. Once I am confident the raw data is not needed, it would be easier to implement the filtering. Then I would average several measurements as quickly as possible or just periodically record the filtered value... probably the latter since that is what is recommended by the app note.
C is a recent addition to the Propeller so that's why most code is in Spin. Most new code though is being done in C to meet educator demand.
Spin is an interpreted and not a compiled language so it's not as fast as compiled C or native machine language.
I personally think that Spin is much easier to learn than C and gives you a better understanding of how the Propeller should you eventually move to Propeller Assembly.
I don't know if you have ever seen PBASIC because that might be easier to understand than Spin and some PBASIC commands are available in the C library.
SHIFTIN and SHIFTOUT are actually PBASIC commands but since they are so powerful and easy to use they were added to the Learn library.
Many very good books were written using the BS2 but unfortunately they are no longer available on the Parallax website. I don't know if they will ever be rewritten to use the Propeller.
I have done a little bit of looking at SPIN as I was developing this sensor to see how they got over the 64-bit math issue. It's definitely not horrible to understand, but they do have some operators and functions that can be difficult to emulate for a novice programmer. Actually, even the advanced programmers I asked had issues figuring out how to duplicate the ** operator in SPIN ("Can't you just use floating point?"). I ultimately had to learn how to hand-calculate binary addition and multiplication and write a function completely on my own just to duplicate a simple SPIN operator.
UPDATE: Attached are a comparison between the pressure sensor on the balloon kit (commercially programmed), and the MS5607 Module I programmed myself. This seems to prove to me that the sensor is working, The jump in the kit's pressure reading is due to it capping out. The other graph is a comparison of the on-board calculation of altitude using linear interpolation (Alt (ft)) to a calculation on my computer without using interpolation (Alt_Calc (ft)). % Error is less than 1% except in the obvious region where the interpolation is just off the reservation. The reason for this huge error seems to be that the altitude falls between the first and second value on the pre-computed altitude table being used for interpolation. For all values where the altitude is less than the 2nd table value, the error is less than 1%. My next steps are to re-code the 2nd order temperature compensation section and then to see if I can fix this interpolation issue.
Parallax makes a nice plastic enclosure that goes around their Prop Proto Board. The Prop BOE is the same dimensions as the BS2 BOE but I don't know if the connectors are in the same place. I don't know if you already have a Prop Plug since the Proto Board doesn't have USB built onto it.
http://www.parallax.com/product/721-32212
http://www.parallax.com/product/32212
Nice job testing your testing and determining it did not fail. If you get some more sensors that would be a good test to put them through before sending them up.
Parallax has GPS modules, Accelerometers, a compass module, temperature and humidity sensors, a pressure sensor, some gas sensors, and a Gyroscope module
The accelerometers both have C code already
http://www.parallax.com/product/28017
http://learn.parallax.com/propeller-c-simple-devices/tilt-and-acceleration-mx2125
http://www.parallax.com/product/28526
http://learn.parallax.com/propeller-c-simple-devices/mma7455-three-axis-accelerometer
I completely agree. I was not thrilled about it either
I think I have all those sensors already, on a prioritized list to get them working. So far, I've gotten data from the gyroscope and 3-axis accelerometer. Now that I've gotten familiar with our vacuum chamber, I will definitely be testing the altimeter in it before sending it back up.