NOTE: GPS units are the LEAST accurate· with height·measurements however.
The·navigation·refresh·is once per second it operates at 4800 Baud.·
It might actually be accurate enough for your needs, BUT... you need to make sure you are receiving GPS data before lauch and that might mean you need to wait... and on a cloudy launch day... it might not work at all.
The spreadsheet is fine. The second set of data, based on the ratiometric output of the analog to digital converter is the one to look at. It uses the typical values right out of the data sheet, that is,
kPa = (ADCreading/4096 + 0.095) / 0.009
Then it uses the standard atmosphere (sea level pressure & temperature 101.3 kPa, 25 degree Celsius, -6.5 degrees per kilometer lapse) to calculate altitude.
If you accept those values, your multiplier in the BS1 should be very close to 7.5 feet per bit from the ADC. So, the BS1 reads the ADC count at launch time. Then subtract each new reading from that initial reading, and multiply that times 7.5, and there should be the altitude in feet. Pretty close.
It might be a few percent off for the following reasons:
1) Your MPX4115 varies a liittle from the standard calibration factor of 0.009. The data sheet specs +/- 1.5%
2) The atmosphere is not the standard atmosphere. Sea level pressure, temperature are not 101.3 kPa and 25 degrees Celsius and the lapse rate is not -6.5 degC per kilometer.
3) You are not launching your rocket at sea level. You need to use a multiplier a little higher, for example, if you are launching from Denver, it will be closer to 8.75 feet per bit.
Again:
'HIGH 3 ' infinite loop
GOSUB Convert
AD = grnd - AD ' difference from ground
feet = AD * 7 ' times 7
feet = AD / 2 + feet ' add 1/2
prev = prev MIN 5 -5 ' noise rejection factor
IF feet<prev THEN Pyro ' going down, deploy chute
IF feet > 750 THEN ' do something spectacular
prev = feet ' update previous for compare
GOTO Again ' Endless loop.
What is the launch altitude? That is what will make the biggest difference in the accuracy. As I said before, 7.5 is the factor for sea level. And there are other "minor" sources of error that can be addressed if it matters.
Once the ground altitude issue is settled, if at all possible, run the code with a debug as you take the system up a hill of known height around 1000 feet to check the differential accuracy. Take your commercial altimeter along too. That is the only way you are going to know how good the accuracy is. It is hard to set up experiments in jars, although it can be done with a U-tube made of flexible tubing, where you can get a measurable head of water or other fluid.
There are two launch sites. The first is about 450 to 460'. The second is about 590' to 600'
Unfortunately, the two hills near me only go up 250' or 100'. Is this good enough? And my commercial altimeter only reports apogee (peak altitude, but the altimeter won't turn on until it goes at least 120 ft up in under 1 second).
And thank you so much for your help [noparse]:)[/noparse]
I tried to make my code a bit better, but now when I run it, it simply beeps a continuous beep for 2.5 seconds (as it should) and then beeps forever (as in "beep-pause-beep-pause" - it should do this a max. of ten times). The code is attached.
A 250 or 100 foot hill will work. An important thing is to know how high it really is. Can you find that information marked on a local map? Find some point at the base where you also know the altitude. Also, on the day when you do the test, try to find out the the barometric pressure and temperature from a local radio station or airport or www.Wunderground.com site.
Knowing the barometric pressure is just a refinement, if you want a little better accuracy on launch day, say 3 feet versus 30 feet.
In your program, you have,
lastRead = lastRead-5
IF lastRead>feet THEN Pyro
Change that to,
lastRead = lastRead MIN 5 - 5
IF lastRead>feet THEN Pyro
You see, lastRead starts out at zero, so that makes lastRead - 5 a negative number, which the IF statement interprets as a very large positive number and jumps directly to the Pyro beep routine. The MIN operator clamps the result to zero or above, until the rocket passes 5 feet.
You might want to change that number from 5 to something like 37. In your original program you were looking at 5 bits, not 5 feet. But 5 bits times 7.5 is 37.5 feet. It depends on the noise or fluctuations in the readings. That is there to detect the point past apogee, and you don't want it to go off simply because of a fluctuation in the reading. 5 bits or 37 feet is a reasonable number.
So does times 7.5 work for both 455 and 595 feet?
The only reason I know it is 250 and 100 feet is by using Google Earth
I tried using
lastRead = lastRead MIN 5 - 5
and it still kept doing the beeping/pausing thing. I don't think it ever goes to PYRO because it never pauses for 3 seconds.
So should the line now be:
lastRead = lastRead MIN 37 - 37
No, each starting altitude has its own factor, and 7.5 applies only for a launch site at sea level. The factor if you are starting at 595 feet is closer to 7.62. First, how do you find that from the spreadsheet that you have? Second, how do you multiply by 7.62 in the program?
Here is the spreadsheet formula that caluclated 7.62. I found an altitude in the chart close to 595, and that is the 583 in cell K800. Then in cell K776 I found an altitude about 750 feet higher, which was the 1330 feet in cell K776. Subtract. The corresponding ADC count outputs are in cells G776 (=3170) and G800 (=3268). Find the difference there, too, and divide, like this:
=(K776-K800)/(G800-G776)
The answer is in feet per bit. That is, each time your ADC conversion changes by one bit, that means that the altitude changes by 7.62 feet..
Now, you try it! What is the multiplier if you start at 455 feet?
Now, how to put 7.62 in PBASIC for the BS1?:
ADCtoFeet:
feet = AD * 7 ' times 7
feet = AD ** 49589 + feet ' add AD*.62 (!!! correction, should be 40589)
RETURN
The ** operator is the Stamp's way of multiplying times fractions like 0.62. What you do to find the factor is to multiply on your calculator (or on the Excel spreadsheet), 0.62 * 65536. That comes out to 49589 40589 (dropping the remainder).
I don't know why your program is beeping, if it is not getting to the pyro routine. You have to insert debug statements in the program to find out where it is gettlng lost and then narrow it down. Put a debug "top" at the very start, just in case the Stamp is resetting from some reason.
I'm curious about what this rocketry contest is all about. Are you a student taking part in a summer program or something like that?
Franklin,
Thanks, you're right. It should be 40589. The discrepancy remaining is that I had the spreadsheet calculate it from the values in the cells, and the actual number it came up with is 0.619345 * 65536 = 40589. Then I typed it wrong. Given the other uncertainties, there is no difference between 0.61945 and 0.62 or .0.63.
This rocketry contest is a national contest run by the NAR and AIA and sponsored by NASA, the DoD and many other aerospace companies. The contest is for middle and high school students across the nation. The contest starts in September (but you can prepare before that, like in my case [noparse]:)[/noparse] ). It ends at the end of May. You get two chances to launch two raw eggs up to 750 feet and keep them aloft for 45 seconds. Then, the top 100 teams across the nation travel to Washington DC for the finals. This year, there were 6 astronauts there as well as the Secretary of Defense, Robert Gates. Most teams (all except 1 or 2) do not use electronic deployment. They use the engine's built in deployment Pyro charge. Unfortunately, that charge can be highly inaccurate. For example, we once had a charge that was supposed to ignite in 6 seconds - it ended up taking 12. The contest's website is rocketcontest.com Oh! And they also hand out really nice prizes. 1st place this year got $15,000 and a trip to the Paris Airshow. Second place got $14,000. Third got $13,000. 4th = $7,000. 5th = $6,000. 6th = $5,000 etc all the way up to tenth place. In addition, the top 25 teams get invited to NASA's SLI, in which they design a rocket and build it with NASA engineers that sends a medical or scientific payload/experiment exactly one mile into the sky.
Good luck with the contest. You are wise to get an early start! Have you seen the film, "October Sky"? The wiki says that is an anagram of "rocket boys", which was the original title of the book. I didn't know that.
Have you had much math? Do you know how to do formulas in Excel spreadsheets?
You asked about DEBUG "top". As the first line in the program:
'THE PROGRAM:
DEBUG CR,"top",CR
If you see "top" on the debug screen, you know that the program is starting. That can be useful in cases where the there is a power supply glitch or a RETURN instruction that does not have a GOSUB to go with it. If the program is restarting when it is not supposed to, then you have to figure out why. DEBUG statements at strategic locations in your program can help you figure things out if it is not going according to plan.
I see a logic error in the program. Feet should be calculated as the distance above the launch point. I put a **** in lines I changed from your last program.
'THE PROGRAM:
DEBUG CR,"top",CR
HIGH CS ' Deactivate the ADC to begin.
GOSUB Convert
ground = AD ' <---- use this value from the ADC as ground, and in the ADCtoFeet routine ****
feet = 0 ' starting at zero ****
lastRead = feet ' also zero
GOSUB BeepOut
GOTO CheckForApogee ' you don't really need this--it is going there anyway!
CheckForApogee:
GOSUB Convert
GOSUB ADCtoFeet
lastRead = lastRead MIN 37 - 37 ' have to experiment with this--is 37 feet to much, too little? ****
IF lastRead>feet THEN Pyro ' pyro when new reading is at least 37 feet less than old reading, descending
lastRead = feet
GOTO CheckForApogee
ADCtoFeet: ' edited ****
AD = AD MIN ground - ground ' clamp AD at ground level ****
feet = AD * 7 ' difference from ground times 7, note MIN clamp to ground ****
feet = AD ** 40589 + feet ' 0.62 ' new math, this for 595 foot launch site. ****
RETURN
' ... other subroutines
I completed Algebra II Honors (and did quite well [noparse]:)[/noparse] ). Next year I'll be taking Precalc Honors.
I changed that code (as well as some other parts), and now is sorta works. When I have the feet beeped out at first, it beeps 0 (which is good). However, when I simulate a rocket flight (create a vacuum), it simply just keeps beeping... no long pauses... [noparse]:([/noparse]
I attached my new code. I don't get what's wrong because it works when I first call it...
And I can't really use DEBUG because the components are already soldered onto my other board... but I was able to figure out the program is not restarting.
Thanks again for all of your help [noparse]:D[/noparse]
and it's the 13th item in that list of downloads. This has nothing to do with making the program look "pretty" but it has everything to do with making it readable.
That aside, I suspect that you will end up in an infinite loop, if you reach the program label "Pyro", because of the following program coding:
Sorry about the lack of readability. This is my first PBASIC program [noparse]:)[/noparse]
I actually want that infinite loop. I want it to beep out the altitude until it is turned off.
BUT... calling DispG should make it beep out the altitude... for 1234 feet, fore example, it would do the following:
beep-long pause-beep-pause-beep-long pause-beep-pause-beep-pause-beep-long pause-beep-beep-bee-beep-uber long pause-<repeat>
That would be good [noparse]:)[/noparse] Instead, it does the following:
beep-pause-beep-pause-<repeat>
I'm still confused about where to put the 0.033uf cap and 750 ohm resistor... I used the Parallax BS1 App Note and there was no mention of either of those [noparse]:([/noparse]
First off, thanks for all of your help [noparse]:D[/noparse]
Secondly, I'm still using the MPX4115AP.
I still don't see the cap or resistor, though! Here is the datasheet I'm referring to: www.freescale.com/files/sensors/doc/data_sheet/MPX4115A.pdf?pspll=1
Here is the document I'm referring to (pic attached). No 750 ohm resistor or .033 cap [noparse]:([/noparse]
No problem for what little help I can give [noparse]:)[/noparse]
Your data sheet is a year newer than mine, so maybe they decided the 750ohm and .33uF aren't needed. You could still try it and see if it works any better for you, if you experiencing jitter. If you would like a copy of the DS I have, email me at:
jpeakall AT madlabs.info
I'd be happy to mail it if the ASCII art ain't cutting it.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.madlabs.info - Home of the Hydrogen Fuel Cell Robot
Because that datasheet is the older version, I think I'll stick with my current setup. Well my stamp got damaged, so I'm awaiting the new one [noparse]:([/noparse]
When you receive your new BS1, it would be great if you can get the program debugged before you install it where it is hard to work with. Resolve that infinite beeping problem. With the Stamp and a beeper attached, and a few strategic DEBUGs, you should be able to track that down in minutes! Also, you can climb up the tallest building or hill you can find and see if the altitude change in feet makes sense.
I see you took care of a couple of variable conflicts in moving from version 2 to version 2(2) of your program. There might still be confilcts. It looks like the use of bit0 in the convert subroutine might conflict with variable W0 as feet, and W1 as AD might conflict with other uses of B2 and B3. Not necessarily, just might--I haven't followed it carefully. The program is not using W4, W5 and W6 yet, so it could be rewritten to have one vairable for each purpose and avoid any chance of conflict. I looks like the subroutine call depth is 4 deep, and that is as deep as it can go. Variable conflicts and violations of Call depth can bring up some pretty weird problems. I don't see what good the dispG subroutine does. It just does a GOSUB work. Why not just GOSUB work directly? Just a few random observations -- you have to dig into it when your new chip arrives!
Sorry for the delay in my reply, but I finally figured out the "infinite beeping problem" When the beeping method is run, "feet" is a negative number. There is a problem with finding the feet based on the ground. I'm a little confused with how to do this.
Should I convert the ground altitude to feet and then subtract the apogee ADC output (after being turned into feet) from ground?
Thanks!
Did you include the (AD MIN ground -ground) code that keeps feet at zero when on the ground? The value of "ground" is determined in the initialization, and is a raw ADC value. From then on, when the program reads the ADC, it first clamps the value to be greater than or equal to "ground". So when converted to feet, it will be positive.
ADCtoFeet: ' edited ****
AD = AD MIN ground - ground ' clamp AD at ground level ****
feet = AD * 7 ' difference from ground times 7, note MIN clamp to ground ****
feet = AD ** 40589 + feet ' 0.62 ' new math, this for 595 foot launch site. ****
RETURN
Aha! That's it. Good thinking! Since AD goes down as altitude goes up, it should be MAX, not MIN:
ADCtoFeet: '
AD = AD MAX ground ' clamp AD value at ground value or less (which means greater altitude)
AD = ground - AD ' difference is positive value
feet = AD * 7 ' difference from ground times 7
feet = AD ** 40589 + feet ' 0.62 ' math fraction for 595 foot launch site. ****
RETURN
Comments
NOTE: GPS units are the LEAST accurate· with height·measurements however.
The·navigation·refresh·is once per second it operates at 4800 Baud.·
It might actually be accurate enough for your needs, BUT... you need to make sure you are receiving GPS data before lauch and that might mean you need to wait... and on a cloudy launch day... it might not work at all.
The spreadsheet is fine. The second set of data, based on the ratiometric output of the analog to digital converter is the one to look at. It uses the typical values right out of the data sheet, that is,
kPa = (ADCreading/4096 + 0.095) / 0.009
Then it uses the standard atmosphere (sea level pressure & temperature 101.3 kPa, 25 degree Celsius, -6.5 degrees per kilometer lapse) to calculate altitude.
If you accept those values, your multiplier in the BS1 should be very close to 7.5 feet per bit from the ADC. So, the BS1 reads the ADC count at launch time. Then subtract each new reading from that initial reading, and multiply that times 7.5, and there should be the altitude in feet. Pretty close.
It might be a few percent off for the following reasons:
1) Your MPX4115 varies a liittle from the standard calibration factor of 0.009. The data sheet specs +/- 1.5%
2) The atmosphere is not the standard atmosphere. Sea level pressure, temperature are not 101.3 kPa and 25 degrees Celsius and the lapse rate is not -6.5 degC per kilometer.
3) You are not launching your rocket at sea level. You need to use a multiplier a little higher, for example, if you are launching from Denver, it will be closer to 8.75 feet per bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Regardless,being able to divide the Adc output by 7.5 to get feet really helps a lot. Thank you [noparse]:D[/noparse]
Again: 'HIGH 3 ' infinite loop GOSUB Convert AD = grnd - AD ' difference from ground feet = AD * 7 ' times 7 feet = AD / 2 + feet ' add 1/2 prev = prev MIN 5 -5 ' noise rejection factor IF feet<prev THEN Pyro ' going down, deploy chute IF feet > 750 THEN ' do something spectacular prev = feet ' update previous for compare GOTO Again ' Endless loop.What is the launch altitude? That is what will make the biggest difference in the accuracy. As I said before, 7.5 is the factor for sea level. And there are other "minor" sources of error that can be addressed if it matters.
Once the ground altitude issue is settled, if at all possible, run the code with a debug as you take the system up a hill of known height around 1000 feet to check the differential accuracy. Take your commercial altimeter along too. That is the only way you are going to know how good the accuracy is. It is hard to set up experiments in jars, although it can be done with a U-tube made of flexible tubing, where you can get a measurable head of water or other fluid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 7/5/2007 9:35:25 PM GMT
Unfortunately, the two hills near me only go up 250' or 100'. Is this good enough? And my commercial altimeter only reports apogee (peak altitude, but the altimeter won't turn on until it goes at least 120 ft up in under 1 second).
And thank you so much for your help [noparse]:)[/noparse]
Thanks once again for all of your help!
Knowing the barometric pressure is just a refinement, if you want a little better accuracy on launch day, say 3 feet versus 30 feet.
In your program, you have,
lastRead = lastRead-5
IF lastRead>feet THEN Pyro
Change that to,
lastRead = lastRead MIN 5 - 5
IF lastRead>feet THEN Pyro
You see, lastRead starts out at zero, so that makes lastRead - 5 a negative number, which the IF statement interprets as a very large positive number and jumps directly to the Pyro beep routine. The MIN operator clamps the result to zero or above, until the rocket passes 5 feet.
You might want to change that number from 5 to something like 37. In your original program you were looking at 5 bits, not 5 feet. But 5 bits times 7.5 is 37.5 feet. It depends on the noise or fluctuations in the readings. That is there to detect the point past apogee, and you don't want it to go off simply because of a fluctuation in the reading. 5 bits or 37 feet is a reasonable number.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
The only reason I know it is 250 and 100 feet is by using Google Earth
I tried using
lastRead = lastRead MIN 5 - 5
and it still kept doing the beeping/pausing thing. I don't think it ever goes to PYRO because it never pauses for 3 seconds.
So should the line now be:
lastRead = lastRead MIN 37 - 37
Thanks!
Here is the spreadsheet formula that caluclated 7.62. I found an altitude in the chart close to 595, and that is the 583 in cell K800. Then in cell K776 I found an altitude about 750 feet higher, which was the 1330 feet in cell K776. Subtract. The corresponding ADC count outputs are in cells G776 (=3170) and G800 (=3268). Find the difference there, too, and divide, like this:
=(K776-K800)/(G800-G776)
The answer is in feet per bit. That is, each time your ADC conversion changes by one bit, that means that the altitude changes by 7.62 feet..
Now, you try it! What is the multiplier if you start at 455 feet?
Now, how to put 7.62 in PBASIC for the BS1?:
The ** operator is the Stamp's way of multiplying times fractions like 0.62. What you do to find the factor is to multiply on your calculator (or on the Excel spreadsheet), 0.62 * 65536. That comes out to 49589 40589 (dropping the remainder).
I don't know why your program is beeping, if it is not getting to the pyro routine. You have to insert debug statements in the program to find out where it is gettlng lost and then narrow it down. Put a debug "top" at the very start, just in case the Stamp is resetting from some reason.
I'm curious about what this rocketry contest is all about. Are you a student taking part in a summer program or something like that?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 7/7/2007 5:40:05 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
Thanks, you're right. It should be 40589. The discrepancy remaining is that I had the spreadsheet calculate it from the values in the cells, and the actual number it came up with is 0.619345 * 65536 = 40589. Then I typed it wrong. Given the other uncertainties, there is no difference between 0.61945 and 0.62 or .0.63.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
What is a debug "top" statement?
This rocketry contest is a national contest run by the NAR and AIA and sponsored by NASA, the DoD and many other aerospace companies. The contest is for middle and high school students across the nation. The contest starts in September (but you can prepare before that, like in my case [noparse]:)[/noparse] ). It ends at the end of May. You get two chances to launch two raw eggs up to 750 feet and keep them aloft for 45 seconds. Then, the top 100 teams across the nation travel to Washington DC for the finals. This year, there were 6 astronauts there as well as the Secretary of Defense, Robert Gates. Most teams (all except 1 or 2) do not use electronic deployment. They use the engine's built in deployment Pyro charge. Unfortunately, that charge can be highly inaccurate. For example, we once had a charge that was supposed to ignite in 6 seconds - it ended up taking 12. The contest's website is rocketcontest.com Oh! And they also hand out really nice prizes. 1st place this year got $15,000 and a trip to the Paris Airshow. Second place got $14,000. Third got $13,000. 4th = $7,000. 5th = $6,000. 6th = $5,000 etc all the way up to tenth place. In addition, the top 25 teams get invited to NASA's SLI, in which they design a rocket and build it with NASA engineers that sends a medical or scientific payload/experiment exactly one mile into the sky.
Have you had much math? Do you know how to do formulas in Excel spreadsheets?
You asked about DEBUG "top". As the first line in the program:
If you see "top" on the debug screen, you know that the program is starting. That can be useful in cases where the there is a power supply glitch or a RETURN instruction that does not have a GOSUB to go with it. If the program is restarting when it is not supposed to, then you have to figure out why. DEBUG statements at strategic locations in your program can help you figure things out if it is not going according to plan.
I see a logic error in the program. Feet should be calculated as the distance above the launch point. I put a **** in lines I changed from your last program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 7/9/2007 2:19:55 AM GMT
I changed that code (as well as some other parts), and now is sorta works. When I have the feet beeped out at first, it beeps 0 (which is good). However, when I simulate a rocket flight (create a vacuum), it simply just keeps beeping... no long pauses... [noparse]:([/noparse]
I attached my new code. I don't get what's wrong because it works when I first call it...
And I can't really use DEBUG because the components are already soldered onto my other board... but I was able to figure out the program is not restarting.
Thanks again for all of your help [noparse]:D[/noparse]
You really, REALLY need to clean up that program a bit, including the use of the style sheet which will help with a better and more readable presentation. The Elements of PBASIC Style can be found here:
http://www.parallax.com/html_pages/downloads/basicstamps/documentation_basic_stamp.asp
and it's the 13th item in that list of downloads. This has nothing to do with making the program look "pretty" but it has everything to do with making it readable.
That aside, I suspect that you will end up in an infinite loop, if you reach the program label "Pyro", because of the following program coding:
CallDispG:
GOSUB DispG
GOTO CallDispG
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I actually want that infinite loop. I want it to beep out the altitude until it is turned off.
BUT... calling DispG should make it beep out the altitude... for 1234 feet, fore example, it would do the following:
beep-long pause-beep-pause-beep-long pause-beep-pause-beep-pause-beep-long pause-beep-beep-bee-beep-uber long pause-<repeat>
That would be good [noparse]:)[/noparse] Instead, it does the following:
beep-pause-beep-pause-<repeat>
I'm not sure if you are stil using the MPX4115 sensor. If you are, the data sheet I have says:
*look out, crude ASCII art follows*
sensor --/\/\/\---|---- ADC input
·············750ohm |
······················· |----||---- gnd
······························ .33uF
It also shows a 1uF and .1uF across the power supply.
Glad your project is working out!
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot
Secondly, I'm still using the MPX4115AP.
I still don't see the cap or resistor, though! Here is the datasheet I'm referring to:
www.freescale.com/files/sensors/doc/data_sheet/MPX4115A.pdf?pspll=1
Here is the document I'm referring to (pic attached). No 750 ohm resistor or .033 cap [noparse]:([/noparse]
No problem for what little help I can give [noparse]:)[/noparse]
Your data sheet is a year newer than mine, so maybe they decided the 750ohm and .33uF aren't needed. You could still try it and see if it works any better for you, if you experiencing jitter. If you would like a copy of the DS I have, email me at:
jpeakall AT madlabs.info
I'd be happy to mail it if the ASCII art ain't cutting it.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot
When you receive your new BS1, it would be great if you can get the program debugged before you install it where it is hard to work with. Resolve that infinite beeping problem. With the Stamp and a beeper attached, and a few strategic DEBUGs, you should be able to track that down in minutes! Also, you can climb up the tallest building or hill you can find and see if the altitude change in feet makes sense.
I see you took care of a couple of variable conflicts in moving from version 2 to version 2(2) of your program. There might still be confilcts. It looks like the use of bit0 in the convert subroutine might conflict with variable W0 as feet, and W1 as AD might conflict with other uses of B2 and B3. Not necessarily, just might--I haven't followed it carefully. The program is not using W4, W5 and W6 yet, so it could be rewritten to have one vairable for each purpose and avoid any chance of conflict. I looks like the subroutine call depth is 4 deep, and that is as deep as it can go. Variable conflicts and violations of Call depth can bring up some pretty weird problems. I don't see what good the dispG subroutine does. It just does a GOSUB work. Why not just GOSUB work directly? Just a few random observations -- you have to dig into it when your new chip arrives!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Should I convert the ground altitude to feet and then subtract the apogee ADC output (after being turned into feet) from ground?
Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Thanks for your help!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com