[noparse]:D[/noparse] that makes sense. I'm not at home now (I'm in China on vacation [noparse]:)[/noparse] ), but as soon as I get home I'll try that out...
Although this will make the altimeter report in feet, this won't fix the accuracy issue, will it? Any suggestions for that problem?
Once you have it reporting in feet (increasing with altitude!), then we can revisit the accuracy issue. It is surmountable! There will be a calibration issue, which will require that you do an experiment and report back the results. And then there is the math issue, which will require that you enter the correct ground level altitude and current barometric pressure and temperature just before each launch. Then it should give very nice results. Have a great China vacation!
One thing to consider is where on the rocket are you taking the altitude reading? I mean do you have an external port where you are taking the pressure reading or is it just inside the rocket itself? Aircraft have their static ports (for altimeter readings) placed in pressure neutral areas of the fuselage. If the location of your pressure reading is not in a neutral spot, accuracy is a bit of a mute point.
I would make an educated guess that a point about 1/4 way down the rocket would be a good point. Be careful about having it on the nose cone, that will be very inaccurate.
Alex,
The rocket does have a static port. In rocketry, the general rule of thumb for altimeter static ports is 2 or 3 body diameters (for a 2.6" diameter rocket, it should be about 1/2 a foot from the bottom of the nosecone). Also, I have not done any testing in the rocket yet... that is (hopefully) going to happen in a few weeks...
Everyone else,
A rocket altimeter company, Transolve, sells a pre-calibrated pressure sensor that has an output of: "0-5V linear, proportional response, 0.25mV/ft." www.transolve.com/Transolve/Files/Products/BaroMod/BaraMod.html
I think this may be more accurate because it is pre-calibrated up to FAA standards. My only question is, with the ADC I am currently using, is it possible to get the voltage from the ADC output?
I'm not definitely going to do this... it is just an idea (I want to get my current setup working!)
THANKS!
EDIT: I just thought of another possible problem... is there any way to tell how many readings are being taken per second? It needs to be in the range of 50 to 100 hz...
I updated the code, and it didn't work. I don't think the ground reading was ever converted to feet. I tried to convert it, but now when I have it beep out the ground it does this (I live at 784'):
<beepx24><beepx1><beepx7><beepx1>
I still think something is not right with converting the ADC output, like 3248, for example, by multiplying it by about 7.5. Wouldn't that give way too high of a result? 3248 is 735 feet...
The variable "ground" in my suggestion was not in units of feet; it was in raw ADC units.
So at the start,
ground = AD ' raw ADC value with rocket on the ground
after that, the number of feet is calculated by
feet = (ground - AD) * 7.5 ' ADC reading goes down as rocket goes up, 7.5 feet per bit.
There were some refinements to that formula to make it compatible with the BS1 and to keep the value positive even if the readings bounce around a little while on the ground.
The point is that the program never calculates the elevation of your launch site above sea level. It only calculates feet above your launch site. If you want feet above sea level, we can make that happen, but it basically is calibrated to the altitude at your launch site.
A traditional aneroid altimeter as would be approved by the FAA is a beautiful piece of equipment, but it is a mechanical device that does not have a lot of math built into it. It has no more brain than your BS1. It has means to enter a current altitude and a current barometric pressure. It mechanically subtracts the current pressure reading from the ground level reading and multiplies times a constant by means of gears and levers. The whole point of the altimeter setting is to allow it to read the correct altitude when you approach an airport and when you are on the ground there. That will work too if you don't travel too far or for too long, but as you approach a new site, you might have to call in for a new altimeter setting.
Does that have anything to do with your rocket? You may have to enter a new altimeter setting for each launch site or if the weather changes. The multiplier will not always be 7.5. 7.5 is just a first approximation, but it should be a pretty good approximation. The ADC value that the program captures each time you run it will change too, with the launch altitude and the weather.
You also asked about the Transolve altimeter. I don't know anything about it and I don't see a manual on line. How, for example, do you enter the altimeter setting? Since you are in school, and one good thing is to learn how things work, I think it's a good idea for you to keep pursuing the BS1 solution. Really understand it!
Thanks for your help. I tried to update the code, but for some reason, PYRO is always being called!
I can't seem to figure out the cause of this... I convert to feet at the end... I check ADC output against ADC output... I am checking correctly (using >)... [noparse]:([/noparse]
You really need to learn how to debug a program! Look at the data that is coming back from the ADC and from the conversion to feet in a simplified loop. Leave out the Pyro routine until you understand what is going on with the measurements.
DEBUG CR,"top",CR
HIGH CS ' Deactivate the ADC to begin.
GOSUB Convert
ground = AD
feet = 0 ' starting at zero ****
lastRead = feet ' also zero
HIGH 3
PAUSE 750
LOW 3
CheckForApogee:
GOSUB Convert
DEBUG AD ' does the raw reading make sense as you change pressure? Tell us what numbers you see.
GOSUB ADCtoFeet
DEBUG feet ' does the conversion to feet make sense? What numbers go with the raw values?
PAUSE 1000 ' 1 second delay
GOTO CheckForApogee
' subroutines as llsted
I can't use "DEBUG" because all of my componenets are already soldered into a board...
However, I used the piezo speaker to beep out the altitude. First, I kept Pyro and had it beep out the value of AD. AD had the value 2473, which is 7184'
Next, I used your code from above.
Here are my results:
Time #1:
AD: 3234 (this is inaccurate, however... I live at 784' and I'm not moving the altimeter from the ground level)
ADCtoFeet call: 14650 (it should be 60')
Time #2:
AD: 3232 (this is inaccurate, however... I live at 784' and I'm not moving the altimeter from the ground level)
ADCtoFeet call: 18766 (it should be 76')
I have no idea what to make of this [noparse]:([/noparse]
ghost13, I don't understand why you can't DEBUG. If you can program the BS1, you should also be able to DEBUG, because the DEBUG output comes back over the programming port.
Nevertheless the beeping method should work for debugging. The beep routine looks okay. As a matter of fact, the beeping is great, because with that you can carry the BS1 up and down some hills and listen to the result.
What makes you think AD=3234 is inaccurate? That's the raw result from the convert subroutine, right? Does that value change when you take the BS1 up and down a hill? Does it stay the same +/- a few counts when you leave the BS1 sitting in one spot?
I can't use DEBUG because all of the parts are soldered onto a separate board. I only use the super carrier for programming...
The beeped out values are first the raw values from the convert subroutine and then the result from ADCtoFeet
Anyways, both of my above results were taken from the same spot ion my house, so they were within 2 counts of one another (a good thing). However, 3232 is 856 feet above sea level. Shouldn't it be reporting 784' (3242)?
And also, the ADCtoFeet subroutine isn't working. It's reading out <beepx14><beepx6><beepx5><beepx0>, which definitely is off (it should be 856').
Are you looking at that Excel spreadsheet to determine the altitude in feet that goes with the ADC reading? Can't do that. The spreadsheet is based on a typical pressure sensor, and there is a statistical spread from part to part in production. Your sensor will be a little different. That would explain why you see 3232 at 784' instead of the typical 3242. Also, that difference might be partially due to the barometric pressure on the day you took your measurement. Reverse your thinking. You now have one calibration point. Your setup returns 3232 at 784' when the barometric pressure is ???.
Even without the parts, you can do some debugging. For example, the ADCtoFeet routine can be tested with numbers you supply from the keyboard. One other thing. The first reading taken by an ADC after power up is sometimes bogus and needs to be thrown away. The first reading determines "ground" level for the ADCtoFeet routine, so it better be correct.
Sorry for the delay in a reply but I've been working hard at this. I ended up getting the transolve sensor, which outputs a voltage. Multiply the voltage times 100 and divide by .25 and you get the altitude. So using the LTC1298 (http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1155,C1001,C1158,P1445#applicationsSection) I have been trying to get the sensor's output voltage. My current equation is returning a negative number.
Any help would be much appreciated. Code is attached.
Thanks
Where did you come up with the maths:
AD = 500000*AD <
This will overflow the 16 bit word
AD = AD/4096
AD = AD/25
AD = AD-500
feet = AD
None of the steps after the first multiplication will mean anything and it is no wonder that the result is weird. If the sensor requires a multiply times 100 followed by a divide by 0.25, that is the same thing overall as times 400. I haven't checked the Transolve data sheet. But a five volt reading, times 400, is only 2000 feet. Can that be right?
On the Stamp you can write the formula to use the ** operator, which is most convenient for math involving fractions between 0 and 1. (AD/4096 is a fraction between 0 and 1).
result = 32000 ** AD
This formula gives result=2000 when AD=4096 at 5 volts input
Thanks for your help. This is the equation I need:
VOUT = ((((5*ADC)/4096)*1000)/0.25)-500
I got this equation by combining my ADC equation and the transolve equation.
How would I put this into BS1 code? Thanks
Okay, if you combine all the constants, (5*1000/0.25 =20000) it comes to...
ALT = 20000 * ADC/4096 - 500
and one possible BS1 equation is...
ALT = ADC * 16 ** 20000 - 500
When ADC=4096, that comes out to ALT = 19995-500 = 19495 feet. And if ADC=0, then ALT = -500 feet.
Hmmm... It seems like Tracy Allen's code is correct... not off by a factor of 10. It is correctly converting it!
Now, the only problem is that it thinks it has reached apogee (the top point) when it hasn't. And it is reporting that it reached 0 feet. It should only report when it has dropped 10 feet below its last reading... and I'm not moving the altimeter at all.
Code is attached.
Any suggestions? Thanks
According to their web site, the conversion is 0.25 millivolt per foot. That's 0.00025 volt per foot, the figure I used the last time for a full scale span of about 20000 feet.
Ghost13, did this baromod come with a decent manual? Helpful? Stamp code?
When you ask for suggestions, it would be helpful for us, and for you, if you present some test readngs you took as two or three columns. The raw AD reading from the converter, the value after conversion to feet, and the decision variables that determine apogee. If the program is thinking apogee when you are not moving the altimeter at all, then that suggests nOIsE and overly permissive progam code.
The Stamp ** operator is not "mod for multiplication". It is a form of multiplicaton followed by division by 65536. O the Stamp you cannot easily work with large numbers, larger than 65536, but with x ** y, the stamp internally forms a 32 bit product x and y, and then also internally divides by 65536, all without overflow. It helps with problems like this, z = x * (y / 65536), where (y/65536) is a fraction between 0 and 1. In your problem, you have
ALT = 20000 * ADC/4096
You can't multiply together 20000 and ADC directly, because the product is too big a number. Instead, massage it to this form,
ALT = 20000 * (ADC * 16 / 65536)
and on the Stamp, the ** operator has the /65536 implied, so
ALT = ADC * 16 ** 20000
Note that ADC*16 is always less than 65536. I changed the order so that it can go on one line without () for the BS1.
After ground reading (PYRO is called):
Sensor VOUT = 368 millivots (960')
Altimeter output = 5' (which means that PYRO should never have been called because of the noise-reduction code.)
Comments
Although this will make the altimeter report in feet, this won't fix the accuracy issue, will it? Any suggestions for that problem?
Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I'll reply when I get back ( < a week) and I'll tell you if that new code is working. Thanks!
One thing to consider is where on the rocket are you taking the altitude reading? I mean do you have an external port where you are taking the pressure reading or is it just inside the rocket itself? Aircraft have their static ports (for altimeter readings) placed in pressure neutral areas of the fuselage. If the location of your pressure reading is not in a neutral spot, accuracy is a bit of a mute point.
I would make an educated guess that a point about 1/4 way down the rocket would be a good point. Be careful about having it on the nose cone, that will be very inaccurate.
Hope this helps
Alex
The rocket does have a static port. In rocketry, the general rule of thumb for altimeter static ports is 2 or 3 body diameters (for a 2.6" diameter rocket, it should be about 1/2 a foot from the bottom of the nosecone). Also, I have not done any testing in the rocket yet... that is (hopefully) going to happen in a few weeks...
Everyone else,
A rocket altimeter company, Transolve, sells a pre-calibrated pressure sensor that has an output of: "0-5V linear, proportional response, 0.25mV/ft."
www.transolve.com/Transolve/Files/Products/BaroMod/BaraMod.html
I think this may be more accurate because it is pre-calibrated up to FAA standards. My only question is, with the ADC I am currently using, is it possible to get the voltage from the ADC output?
I'm not definitely going to do this... it is just an idea (I want to get my current setup working!)
THANKS!
EDIT: I just thought of another possible problem... is there any way to tell how many readings are being taken per second? It needs to be in the range of 50 to 100 hz...
<beepx24><beepx1><beepx7><beepx1>
I still think something is not right with converting the ADC output, like 3248, for example, by multiplying it by about 7.5. Wouldn't that give way too high of a result? 3248 is 735 feet...
So at the start,
ground = AD ' raw ADC value with rocket on the ground
after that, the number of feet is calculated by
feet = (ground - AD) * 7.5 ' ADC reading goes down as rocket goes up, 7.5 feet per bit.
There were some refinements to that formula to make it compatible with the BS1 and to keep the value positive even if the readings bounce around a little while on the ground.
The point is that the program never calculates the elevation of your launch site above sea level. It only calculates feet above your launch site. If you want feet above sea level, we can make that happen, but it basically is calibrated to the altitude at your launch site.
A traditional aneroid altimeter as would be approved by the FAA is a beautiful piece of equipment, but it is a mechanical device that does not have a lot of math built into it. It has no more brain than your BS1. It has means to enter a current altitude and a current barometric pressure. It mechanically subtracts the current pressure reading from the ground level reading and multiplies times a constant by means of gears and levers. The whole point of the altimeter setting is to allow it to read the correct altitude when you approach an airport and when you are on the ground there. That will work too if you don't travel too far or for too long, but as you approach a new site, you might have to call in for a new altimeter setting.
Does that have anything to do with your rocket? You may have to enter a new altimeter setting for each launch site or if the weather changes. The multiplier will not always be 7.5. 7.5 is just a first approximation, but it should be a pretty good approximation. The ADC value that the program captures each time you run it will change too, with the launch altitude and the weather.
You also asked about the Transolve altimeter. I don't know anything about it and I don't see a manual on line. How, for example, do you enter the altimeter setting? Since you are in school, and one good thing is to learn how things work, I think it's a good idea for you to keep pursuing the BS1 solution. Really understand it!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I can't seem to figure out the cause of this... I convert to feet at the end... I check ADC output against ADC output... I am checking correctly (using >)... [noparse]:([/noparse]
You really need to learn how to debug a program! Look at the data that is coming back from the ADC and from the conversion to feet in a simplified loop. Leave out the Pyro routine until you understand what is going on with the measurements.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
However, I used the piezo speaker to beep out the altitude. First, I kept Pyro and had it beep out the value of AD. AD had the value 2473, which is 7184'
Next, I used your code from above.
Here are my results:
Time #1:
AD: 3234 (this is inaccurate, however... I live at 784' and I'm not moving the altimeter from the ground level)
ADCtoFeet call: 14650 (it should be 60')
Time #2:
AD: 3232 (this is inaccurate, however... I live at 784' and I'm not moving the altimeter from the ground level)
ADCtoFeet call: 18766 (it should be 76')
I have no idea what to make of this [noparse]:([/noparse]
Thanks for your help...
Nevertheless the beeping method should work for debugging. The beep routine looks okay. As a matter of fact, the beeping is great, because with that you can carry the BS1 up and down some hills and listen to the result.
What makes you think AD=3234 is inaccurate? That's the raw result from the convert subroutine, right? Does that value change when you take the BS1 up and down a hill? Does it stay the same +/- a few counts when you leave the BS1 sitting in one spot?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
The beeped out values are first the raw values from the convert subroutine and then the result from ADCtoFeet
Anyways, both of my above results were taken from the same spot ion my house, so they were within 2 counts of one another (a good thing). However, 3232 is 856 feet above sea level. Shouldn't it be reporting 784' (3242)?
And also, the ADCtoFeet subroutine isn't working. It's reading out <beepx14><beepx6><beepx5><beepx0>, which definitely is off (it should be 856').
thanks for all of your help!
Even without the parts, you can do some debugging. For example, the ADCtoFeet routine can be tested with numbers you supply from the keyboard. One other thing. The first reading taken by an ADC after power up is sometimes bogus and needs to be thrown away. The first reading determines "ground" level for the ADCtoFeet routine, so it better be correct.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Any help would be much appreciated. Code is attached.
Thanks
Where did you come up with the maths:
AD = 500000*AD <
This will overflow the 16 bit word
AD = AD/4096
AD = AD/25
AD = AD-500
feet = AD
None of the steps after the first multiplication will mean anything and it is no wonder that the result is weird. If the sensor requires a multiply times 100 followed by a divide by 0.25, that is the same thing overall as times 400. I haven't checked the Transolve data sheet. But a five volt reading, times 400, is only 2000 feet. Can that be right?
On the Stamp you can write the formula to use the ** operator, which is most convenient for math involving fractions between 0 and 1. (AD/4096 is a fraction between 0 and 1).
result = 32000 ** AD
This formula gives result=2000 when AD=4096 at 5 volts input
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
VOUT = ((((5*ADC)/4096)*1000)/0.25)-500
I got this equation by combining my ADC equation and the transolve equation.
How would I put this into BS1 code? Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
VOUT = ((5*ADC)/4096)
ALT. = ((VOUT*1000)/.25)-500
Any advice on converting this to Basic Stamp Code?
Thanks
Also, I am currently using the VOUT equation from someone else... I couldn't find the equation on the datasheet...
ALT = 20000 * ADC/4096 - 500
and one possible BS1 equation is...
ALT = ADC * 16 ** 20000 - 500
When ADC=4096, that comes out to ALT = 19995-500 = 19495 feet. And if ADC=0, then ALT = -500 feet.
Do you understand the Stamp ** operator?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
So your calculation is off by a factor of 10.
Simplifying your equation to··· ALT. = (VOUT*400)-500
I'm not sure why there is the 500 in there.
Hope this helps.
- Bob -
I still don't understand the ** function completely. Is it like mod for multiplication?
The 500 is there because 0.0 volts is -500 feet.
Thanks again for all of your help. I'll try it now and report back.
Now, the only problem is that it thinks it has reached apogee (the top point) when it hasn't. And it is reporting that it reached 0 feet. It should only report when it has dropped 10 feet below its last reading... and I'm not moving the altimeter at all.
Code is attached.
Any suggestions? Thanks
Ghost13, did this baromod come with a decent manual? Helpful? Stamp code?
When you ask for suggestions, it would be helpful for us, and for you, if you present some test readngs you took as two or three columns. The raw AD reading from the converter, the value after conversion to feet, and the decision variables that determine apogee. If the program is thinking apogee when you are not moving the altimeter at all, then that suggests nOIsE and overly permissive progam code.
The Stamp ** operator is not "mod for multiplication". It is a form of multiplicaton followed by division by 65536. O the Stamp you cannot easily work with large numbers, larger than 65536, but with x ** y, the stamp internally forms a 32 bit product x and y, and then also internally divides by 65536, all without overflow. It helps with problems like this, z = x * (y / 65536), where (y/65536) is a fraction between 0 and 1. In your problem, you have
ALT = 20000 * ADC/4096
You can't multiply together 20000 and ADC directly, because the product is too big a number. Instead, massage it to this form,
ALT = 20000 * (ADC * 16 / 65536)
and on the Stamp, the ** operator has the /65536 implied, so
ALT = ADC * 16 ** 20000
Note that ADC*16 is always less than 65536. I changed the order so that it can go on one line without () for the BS1.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I've attached the manual. In my last test, here are the results:
During ground reading:
Sensor VOUT = 368 millivots (960')
Altimeter output = 960'
After ground reading (PYRO is called):
Sensor VOUT = 368 millivots (960')
Altimeter output = 5' (which means that PYRO should never have been called because of the noise-reduction code.)