MS5607 Altimeter (Product ID: 29124) Testing and Data Processing
c07Brian.Kester
Posts: 36
I've been working on getting the MS5607 Altimeter (Product ID: 29124) working for a while and I have finally gotten to the point where the data I'm getting is somewhat close to reality, but I still don't trust it. I am programming in Propeller C on a Propeller Activity Board using SPI and I am at the Air Force Academy in Colorado at approximately 7300 ft (2225 m). The temperature seems accurate enough, at least inside, but the pressure is off by ~(-300 mbars). When measuring temperature outside in direct sunlight, the temperature value was off by approximately 9 deg C, though inside, it appears to be accurate. My questions are:
1) The sensor is factory calibrated and already has offsets, so I am wondering if it is still standard practice to add an additional offset.
2) If I do add an offset, what is the best way to calibrate? Should I just take some measurements outside with known pressure/temperature values? I have access to a thermal vacuum chamber, but this seems excessive.
3) The nearest weather sensor gives pressure in "in Hg." I found a conversion on-line, but it converts from "in Hg (32F)" to mbar. Since it indicates "32 F," I assume the conversion might be different at our actual temperature around 70 deg. Is that significant?
4) I have run into issues with needing 64-bit variables for the conversion from digital counts to actual temp/pressure. 64-bit variables do not appear to be supported on the Propeller chip. Is there a way around this limitation?
5) Is there a reason why the temperature sensor would be accurate inside, but inaccurate outside?
Any insight into any of these issues would be appreciated!
1) The sensor is factory calibrated and already has offsets, so I am wondering if it is still standard practice to add an additional offset.
2) If I do add an offset, what is the best way to calibrate? Should I just take some measurements outside with known pressure/temperature values? I have access to a thermal vacuum chamber, but this seems excessive.
3) The nearest weather sensor gives pressure in "in Hg." I found a conversion on-line, but it converts from "in Hg (32F)" to mbar. Since it indicates "32 F," I assume the conversion might be different at our actual temperature around 70 deg. Is that significant?
4) I have run into issues with needing 64-bit variables for the conversion from digital counts to actual temp/pressure. 64-bit variables do not appear to be supported on the Propeller chip. Is there a way around this limitation?
5) Is there a reason why the temperature sensor would be accurate inside, but inaccurate outside?
Any insight into any of these issues would be appreciated!
Comments
There are several different algorithms that can be used to extrapolate to sea level, using the standard atmosphere formulas with/without standard/special corrections for lapse rate (temperature vs altitude). Discrepancies are not unheard of.
For the math, I suppose you have looked at the Spin version? It's pretty easy to try the well vetted demo to compare with your own code. Phil made good use of his umath.spin methods, 64 bit unsigned. I have no idea how much work it would take to convert that to C (but don't ask Phil to C it!!)
I think link has the information you need.
http://forums.parallax.com/showthread.php/134753-Parallax-s-New-Altimeter-Barometer-Module?highlight=MS5607
This is from #37
Here's a chart you can use to adjust your pressure readings (approximately) to sea level:
http://www.novalynx.com/manuals/bp-e...ion-tables.pdf
Find your altitude on the chart, then add the deviation from zero to your pressure reading to get the adjusted reading.
This is from #68
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
I hope that helps.
I checked and I have a copy of that table on my hard drive so here you are.
Parallax-s-New-Altimeter-Barometer-Module
My first problem is that there does not appear to be a comparable operator to "**" in C, so I started down the path of creating my own function to accomplish this that can work with Propeller C. I THINK I came up with a viable solution and would appreciate any feedback. The test script is below. I plan to turn this into a function called mult_high to return the same result as the "**" operator in SPIN and then try to follow along the logic from the SPIN code above. I figure there are probably a couple more hurdles to overcome in implementing the "_dadd" "_umult" and "~>" functions above, but it seems doable. I'll post the final result once I'm done in case anyone is interested.
#include "simpletools.h" // Include simple tools int A=-2147483405, B=-2147482751; int mask_low=0x0000FFFF; char sign=1; unsigned int AH,AL,BH,BL; unsigned int BLAL,BLAH,BLA,BLA1,BLA2,BHAL,BHAL1,BHAL2,BLA_BHAL1,BLA_BHAL,BHAH; int main() // Main function { unsigned int Result_Low=A*B; /*First check for and store sign of result*/ char signA=((unsigned int) A&1<<31)>>31; char signB=((unsigned int) B&1<<31)>>31; if (signA!=0) A=-A; if (signB!=0) B=-B; if ((signA==0&&signB==0)||(signA!=0&&signB!=0)) sign=0; print("signA=%d, signB=%d, sign=%d\n",signA, signB, sign); /*Break numbers into halves*/ AH=(unsigned int) A>>16; AL=A&mask_low; BH=(unsigned int) B>>16; BL=B&mask_low; print("A=%d\nB=%d\nAH=%d, AL=%d\nBH=%d, BL=%d\n\n",A,B,AH,AL,BH,BL); BLAL=(BL*AL)>>16; //Shifted to the right to line up with BLAH BLAH=(BL*AH); BLA=BLAL+BLAH; BLA1=BLA&mask_low; BLA2=BLA>>16; // print("BLAL=%b\n BLAH=%b\n BLA=%b\n BLA1=%b\n BLA2=%b\n",BLAL,BLAH,BLA,BLA1,BLA2); BHAL=(BH*AL); BHAL1=BHAL&mask_low; BHAL2=BHAL>>16; // print("BHAL=%b\n BHAL1=%b\n BHAL2=%b\n",BHAL,BHAL1,BHAL2); BLA_BHAL1=(BLA1+BHAL1)>>16; BLA_BHAL=BLA2+BHAL2+BLA_BHAL1; BHAH=(BH*AH); // print("BLA_BHAL1=%b\n BLAH_BHAL=%b\n BLA=%b\n BHAH=%b\n",BLA_BHAL1,BLA_BHAL,BHAH); signed int Result_High=BLA_BHAL+BHAH; if(sign==1) Result_High=~Result_High; print("Result_High = %x\n",Result_High); print("Result_Low = %x",Result_Low); }The code above was written with the logic of doing binary multiplication by hand, accounting for all carries and truncating off the lower 32 bits of the final answer without ever using a variable or intermediate result of larger than 32 bits. The inputs A and B could be any signed 32-bit int. Again, any feedback would be welcome... I am certainly a novice programmer and there's probably a more efficient way to do this... that, and I just learned how to do binary arithmetic yesterday...
if(sign==1) Result_High=~Result_High; if ((A*B)==0x00000000) Result_High+=1; print("Result_High = %x\n",Result_High); print("Result_Low = %x",Result_Low);I wrote firmware for the MS5606/MS5803 for the BASIC Stamp. The Stamp has only 16 bit integers, so the formulas as given would have required triple or quad precision. I found it possible to refactor the math so that the intermediate results fit in 32 bits. I'm attaching an exploratory spreadsheet--Oh, but I'm hazy on how it worked now. The Stamp program does make heavy use of its ** operator.
https://github.com/libpropeller/libpropeller/blob/master/libpropeller/ms5611/ms5611.h
It shouldn't be very difficult to convert from C++ to C, if that's what you want. C++ is really a few things bolted onto C so it's pretty easy to pick up. And, in any case, the math part should be pretty much cut and paste if you so wish.
The C++ code looks rather foreign to me. It seems to be an entirely different way/style of coding, which is rather daunting to a novice programmer such as myself.
Regardless, the C code appears to need more than cut and paste in the math. I tried that and I'm getting out gibberish for everything after the temperature. Although, the code for the temperature DID work and that saved me a few lines of code, so that was good at least. C just doesn't seem to handle the int64_t data type the same. SIDE did not give me an error, but it DID color the int64_t the same color as it does the word "include" in the statement "#include" if that makes sense. Normally data types are colored blue, but it colored int64_t the puke yellow color. I also noticed some of the shifts (specifically for c1_ and c2_) are slightly off. My data sheet says to shift them 16 and 17 respectively while the code on libpropeller shifts them only 15 and 16.
Is there something I may be missing?
In the meantime, I'm back to using my custom functions. I've created functions to return the upper 32 bits when adding and multiplying and have been able to calculate up through SENS. The last thing to figure out is the final calculation of pressure.
_cur_temp_press_5611
and
_cur_temp_press_5607
Parallax subsequently settled on using the '5607 in the product #29124.
Differences (that I know of) compared to the SPIN code:
1) Not as user-friendly... no options to report avg, median values or do unit conversions
2) Only uses linear interpolation between points on the altitude table
3) Uses the stratosphere pressure/altitude model for altitudes above 11,000m (the SPIN code appears to use only the troposphere model)
4) Used excel to generate the altitude table which resulted in slightly different values even when using the same model
5) User can only enter a local sea-level pressure correction to the altitude model rather than the option to enter starting altitude and compute the local sea-level correction.
6) No user interface. All user-selected values (such as local sea-level pressure correction) would have to be manually entered into the code, though I did try to make this easy by having those values one might want to change at the top with comments.
There are probably a number of other differences, but those are the main ones I can think of. Most of them could probably be easily modified, but the code appears to work for my uses and it did not seem to be worth my time to make it more robust. I can attach the latest version of the C code, but it relies on a small personal library for the 64-bit integer math and I wasn't sure what I would need to do to include that.
PS> There's some links here but they don't work any more.