I'm off for a couple of days to play folk music at a hootenanny tonight, then celebrate the 4th with my girlfriend away from the madness that we get here on the Milwaukee lakefront. It's the closing weekend of Summerfest, with the big fireworks display tonight, and I'd rather be elsewhere.
Here (attached) is my idea of fun fireworks. It's the upper half of the rocket I flew with radio-controlled deployment a couple of years ago, and the motor casing for the "K" class motors it flies on. I've got a K805 Mojave Green to fly it on in a couple of weeks, if the weather cooperates. 15 pounds, about 8' 4" tall, carries a MAWD altimeter and a Missileworks WRC digital radio receiver. It has flown 6 times, all on K motors (K550, K695).
I spent an hour or so this morning trying to get my MAWD setup to work with a Propeller. I made some progress, as I can get the Prop to reliably send data to Excel, but I'm not reading the XBee data yet. It just needs more time. One thing that I like about projects like this is that in the process you inevitably learn some things you're going to need later. I'd never used PLX-DAQ with a Prop - it turns out it's incredibly easy.
·· Cool rocket! And it's 8-1/2 feet tall and it flies on a 'K' motor? What kind of altitude do you get? Is it 6" diameter like the ARLISS rocket?
I'm curious how a "radio-controlled deployment" works. I've considered this idea before (but my garage door opener deesn't quite have the transmit distance.) Is it a remote-controlled deployment system,like a remote-controlled airplane? What happens if the rocket is out of range, or if you can't see·the rocket·to determine when to deploy (or if the batteries aren't strong enough, etc.)? Is there a back-up deployment system?
So what instrument do you play at the hootenanny? A fiddle? A guitar? I envy people who are musically talented (like my wife and son.) I couldn't play a note to save myself.
Looks like Tracy is a having a fun-filled 4th of July, too. He's at a place called Half Moon Bay (sounds bucolic) to
>·
maybe see the highly unofficial and tenuously illegal fireworks displays individuals shoot off on many of the small beaches in Santa Cruz. Some of these people have serious skyrockets. Fun, close up, and slightly dangerous, like old times.
Now you're talking our langauge, Tracy! Have fun, and be safe.
·· Cool rocket! And it's 8-1/2 feet tall and it flies on a 'K' motor? What kind of altitude do you get? Is it 6" diameter like the ARLISS rocket?
I'm curious how a "radio-controlled deployment" works. I've considered this idea before (but my garage door opener deesn't quite have the transmit distance.) Is it a remote-controlled deployment system,like a remote-controlled airplane? What happens if the rocket is out of range, or if you can't see·the rocket·to determine when to deploy (or if the batteries aren't strong enough, etc.)? Is there a back-up deployment system?
So what instrument do you play at the hootenanny? A fiddle? A guitar? I envy people who are musically talented (like my wife and son.) I couldn't play a note to save myself
I played guitar and sang at the hootenanny - I also play banjo and piano at times. If timing works out right, I'll get to play and sing at Irishfest this year (ironic, as I have almost no Irish blood). I'm mainly a harmony singer.
The rocket is made from 5.5" diameter LOC, and it's built like a tank (fiberglass/epoxy), so it makes only about 2800' on a K 550. On the K805 it should barely crack 3000'.
The radio control unit I used in it is a now-discontinued Missileworks WRC. It's a very big unit - I don't think it'd fit into anything smaller than 5.5" tubing - and requires an 11-14VDC onboard power supply (I'm using a 9V battery in series with two AA cells). It operates in the 900 MHz range, spread spectrum, and uses digital codes to safeguard against accidental firing. The radio range is good - it fired reliably each time that I used it (though the first unit I received only worked if the transmitter was right next to the receiver - it was defective, and readily replaced by the maker). It's really fun to be standing on the ground watching your rocket coming in, and push a button to deploy the main parachute. I don't know what it would take to be out of range, but you'd surely be out of sight before that.
I did use a MAWD as backup. Actually, I let the MAWD fire the apogee charge, with a backup charge for that wired to the radio control (so the radio control backed up the altimeter for the apogee charge). Then the MAWD was set to fire the main at a relatively low altitude as backup for the radio control. I never needed the backups - in fact, I've never had a charge fail to fire in any of my rocket flights. These things are pretty reliable if you know your devices and take care in wiring things. I've also flown that same rocket with two MAWDs, one set to fire at apogee, the other a second later, and then one set to deploy the main at 700 feet, with the other backing that up at 500 feet (or maybe it was 900' and 700' - I don't remember). Again, worked perfectly.
I did fire the backup apogee charges after all of the other charges had fired. It's important NOT to land with live charges in your rocket, for fairly obvious reasons. I waited until after all of the other events had happened because I didn't want to risk the backup apogee charge knocking the main chute out before I was at low altitude. It was really interesting to set up those events and work my way through the checklist during flight.
The WRC was expensive and huge, as I mentioned, and you could surely build a reliable one that was much smaller and at least a little cheaper using XBee 900 MHz radios, maybe a Stamp onboard (though it might be possible to do without, but that's beyond my ability), and a simple firing circuit. Word is that the Missileworks guy (Jim Amos) is working on a smaller replacement system.
My name is Jessica and I am on Mark Kibler's ARLISS team. You said for the radio control to be out of range we'd have to be out of sight. We were pretty much expecting to be out of sight of the rocket after it's launched. How would we know when to press the button?
My name is Jessica and I am on Mark Kibler's ARLISS team. You said for the radio control to be out of range we'd have to be out of sight. We were pretty much expecting to be out of sight of the rocket after it's launched. How would we know when to press the button?
First of all, I don't think you're working on a system that needs this kind of radio control, are you? I think that this isn't an issue for your project, right?
The project I was using this radio on was one for which we wanted to open a parachute at a certain point. The rocket had come back down into our visual range by the time we needed to open the parachute. If you needed to signal the rocket at a certain time while it was still out of sight, you'd need some kind of indicator of the right time. What you used would depend on the project.
Sylvie, · Just wondering here, would it be possible for us to use a radio control with our project? Also,·are you suggesting that we should use·a radio control·or not? · Thank you for your time and help, · Sean from ARLISS-NH
·· Thanks for answering the kids' question. Keep in mind that most of this·is brand new to literally half the team, and the techno-speak that you, Tracy and I toss back and forth easily might seem like Greek to them. A pat on the back to each of these young Rocketeers·for daring to ask the questions! Two pats on the back-- to you and Tracy-- for answering them, and for helping us figure out the programming (which·is like Greek to me half the time!) Thanks. You're teaching and inspiring some bright young minds.
Jess,··
·You asked a great question ·· about being able to see the rocket. Let me explain two terms that·are similar·but which mean two different things:
1) "Line of sight"·refes·to radio·wave·transmission. If·a radio wave receiver·(our 'Beast-finder') is strong enough-- and if there is nothing between the rocket's transmitter·and the receiver-- you should be able to receive a signal even though you can't see the rocket. The radio wave follows an invisible, make-believe "line of sight" between the transmitter and receiver, even if they're 20 miles apart. If you block the signal (the 'line of sight') with a hill, a forest, even a large cluster of trees or a building, the radio wave is blocked and the signal·may not·get through.
2) 'Visibility' means that you have a clear 'line of sight' to the object. You can see it until it disappears which, like you said, our rocket definitely will do. But just because we can't see the rocket doesn't mean that it doesn't have "line of sight" radio transmission. The rocket is·certainly up there somewhere--in a direct line with us on the ground--but we can't see it because it's up too high. That's why we·need a transmitter: to find it. That's why we want a transmitter with the greatest signal strength: to increase it's line of sight distance, so we don;tlose everything.
Great question Jess!
Sean,
· You asked another good question · (I actually had the same question·for Sylvie, but you asked it first!) I'm pleased that·you're reading the forum·thoroughly enough to ask the question. After reading Sylvie's reply I suppose we could use·a radio controlled ejection as a back-up, but you have to answer this questions first: what resources does it require (materials, time, the brain power to build it, space on the ASP, etc.) Which of these resources do we have; which don't we have? Is the idea practical? Will it help the project,slow things down, or have no effect? Foof for thought, young Rocketeer, and another great question!
I'll see you Rocketeers this Sunday for practice. Keep reading the forum and asking questions. This is how you learn. The information we glean this we, we'll need to apply on Sunday...!! I'll look for more of your questions and commenst on the forum.
Rocketeers should realize every project that involves several people will have side tracks, and that talking about those is part of the process! It is human nature, makes life interesting, and often leads to directly relevant insights and sometimes emphatically not. It is a very useful skill to be able to separate the core issues from the sidetracks.
·· You're absolutely right: seemingly 'off-topic' questions and·discussion often lead to directly relevant insights, sometimes emphatically not. It is a very useful skill to be able to separate the core issues from the sidetracks.
There's a·beauty and a synergy here. Sometimes these off-topic questions and ideas lead to new discoveries and inventions! It's the difference between being good end-users of current technology, or·developers of future technology. 1+1+1 sometimes does equal 4, even 5. That's synergy, and that's what we're all about.
Tracy Allen said...
Rocketeers should realize every project that involves several people will have side tracks, and that talking about those is part of the process! It is human nature, makes life interesting, and often leads to directly relevant insights and sometimes emphatically not. It is a very useful skill to be able to separate the core issues from the sidetracks.
Ah, excellent point. In my experience, it's always good to have explored what's possible, even when you don't need it at the moment. Then later when a new problem arises, you just might already have the solution in hand.
I have a whole bunch of devices sitting around here that I've never put to any real use, but I did play around with them enough to get 'em working when I got 'em. That is, in fact, how I knew how to communicate with the MAWD back over a year ago.
We ended up not going to the beach to see fireworks on the 4th, because the people we were staying with had a dog at home that needed to have company so as not to be freaked out by explosions, whistles, sirens and pop-pop-pops, not to mention the sulfer in the air (over 100 million particles of 0.5 micron and up per cubic meter, according to an air quality monitor I was carrying along). I hope no-one gets the idea that I am suggesting that we launch a dog in the rocket!
The dog is a Gordon Setter, a truly huge breed. We took him to the parade earlier in the day. It was so big it turned heads and made small children run for their mothers, but the dog is really an emotional pushover, but physically you don't want him to lean on you. The parade in Watsonville was interesting with a heavily Mexican American influence, with Mariachi Bandas, farm machinery, pimped up cars, and hundreds of fancy prancing horses. The following day we passed through a small town where the local volunteer fire department had their annual pancake breakfast, and it is always fun to get in on a local event like that. And then we worked off the pancakes with a hike in the redwoods. A great and relaxing time overall.
Back to topic. Sometime back I think Mark mentioned that he had acquired a methane sensor from Parallax. I don't recall if there was any thought of using that in the rocketeers' ASP. Methane is one of the heat trapping gases that along with CO2 has increased considerably in the upper atmosphere in the past couple of centuries. I would leave it as a problem for a rocketeer, what is the situation with methane in the atmosphere, and would the sensor be capable of detecting anything useful?
···· The pancake breakfast and a hike through the woods sounds like a nice trade-off to traditional fireworks (especially if they would excite a house-sized dog! How big is your dog anyway? The size of a Great Pyrenees or a St. Bernard?)
We did acquire a Parallax methane sensor but we have no plans for using it on the ASP right now. We have to get the MAWD wiring and programming firmed up first (and there's no room on the curent BOE-ASP circuit board. The modular methane sensor requires 4 open pins and more space than we have available.) Maybe we could add it as a "stand-alone" sensor on another BOE board once we get the ASP fully functional. Maybe.
So where do we go with programming the MAWD-BOE from here? I tried cutting-and-pasting the MAWD program you wrote earlier into the "ASP" (robot) program without much success...
···· The pancake breakfast and a hike through the woods sounds like a nice trade-off to traditional fireworks (especially if they would excite a house-sized dog! How big is your dog anyway? The size of a Great Pyrenees or a St. Bernard?)
We did acquire a Parallax methane sensor but we have no plans for using it on the ASP right now. We have to get the MAWD wiring and programming firmed up first (and there's no room on the curent BOE-ASP circuit board. The modular methane sensor requires 4 open pins and more space than we have available.) Maybe we could add it as a "stand-alone" sensor on another BOE board once we get the ASP fully functional. Maybe.
So where do we go with programming the MAWD-BOE from here? I tried cutting-and-pasting the MAWD program you wrote earlier into the "ASP" (robot) program without much success...
Mark
Mr. Kibler, I assume that when you posted the MAWD program into the ASP (robot) program that you made the MAWD program a subroutine of the ASP (robot) program. Now, in the ASP (robot) program, there is already a subroutine to record the data to the data logger. What we need to do is copy and paste the MAWD program into the ASP (robot) program (like you already did) and determine the point in the program where the MAWD subroutine should be initiated. We·also need to·figure out if there are any duplicate details in the two programs (possibly recording on the data logger) and merge the programs together. · Hello from Terrorism camp, · Tyler Becker · · P.S. My class is called International Terrorism and Political Violence for everyone else reading this thread. · P.S.S. I like the patches. Nice job Mr. Kibler!
Post Edited (Tyler from ARLISS NH) : 7/9/2009 11:45:44 PM GMT
··· I'm glad to hear that you're enjoying the St. Pauls' Advanced Study Program ("terrorism school" as you so eloquently call it!) I just got an e-mail from Andrew and he reports that he's having a super time at Phillips-Exeter's Math, Science and Technology program (I'm not sure what interesting nickname he has for it... yet!) They call him, appropriately,·"the kid from NASA." Have you seen Mollie at St. Paul's? She's studying German, right?
You're on target with your suggestions and insights. Theoretically the MAWD program·should be imbedded into the ASP program as a subroutine: "...copy and paste the MAWD program into the ASP (robot) program and determine the point in the program where the MAWD subroutine should be initiated." Practially though, I haven't got it to work... yet.·Here's where we need to ask for and rely on expert help.·I·tried cutting-and-pasting Mr. Allen's··MAWD subroutine into the ASP program, with curious but unsuccessful results.·First it caused the Datalogger to record temperature and humidity twice as fast (a good thing actually.) Another time the Datalogger "sped up" while the MAWD was running in the vacuum chamber; then it slowed down to "normal" speed when the MAWD reached 1 ATM (1 atmospheric pressure, or 62.4 lbs/in2.) But I never did get it to write·altitude data to the Datalogger.·So I'm a bit miffed-- stumped-- puzzled-- boggled--- but it's fun trying! I also read the book, which I'm slowly understanding. For now, though, I'll defer to Mr. Allen, and hope the he can help us out the programming as he did last year.
I'm glad you like the mission patch. They were designed and made with help from "your friends at NASA." It's amazing just how many friends you guys (and gals) have, and how your success follows you far and wide. Keep up the good work Tyler, and have fun at St. Paul's. And make lots of new friends...! Thanks for checking in on the forum. I'll see you on Sunday at 1 PM.
I'm attaching an update of the program. dateline July 10th. Mark, the starting point was your last posted version, "MAWDBOE_July01.BS2". There are comments in the revision section.
This adds support for the MAWD, in terms of capturing the altitude data and storing it in the log file. Each record in the log file is now 29 bytes with the added 5 digit altitude field and a comma. Also, it synchronizes the data logging to the clock, so that it scans at exactly 5 second intervals, or whatever number you enter in the CONstant "logInterval".
I am using a MAWD simulator made from another BASIC Stamp, which sends out a fake altitude string at 50 millisecond intervals. I don't have a real MAWD. So there may well be some issues there. I have it assigned to pin p3, but of course you can change that.
MAWDin PIN 3
I used altered wiring to the Stamp for the DS1302, that being Stamp pins p7, p6, and p5 instead of p2, p5 and p7. There are a couple of reasons that I did that, and I was going to change it back, but forgot until just now. You should change those pin definitions back to match what exists on your BOE.
· We (Christopher and I) downloaded and tried your new·program this morning and it works well! When we put the MAWD in the vacuum chamber the altitude data read out on the screen along with temperature, humidity, and time (in my excitement I didn't remove the flash drive to see the data file, but I'm sure it's there.) After we changed pins 7, 6,and 5 back to 2, 5 and 7·like you suggested, it also showed elapsed time. This is a major milestone, and an excellent starting point for tomorrow's "all team" practice.
One observation that I'll explore more today is the fact that·the altitude on the new program appears to read "high." For example, when I run your first 'simple' altitude program on a bare BOE, the altitude reaches approximately 7,000 pressure altitude feet when the vacuum pump·is drawing·200 psi. On the new MAWDBOE_July10ta.bs2··program, it's more than double that. I'll re-test this afternoon and get you some more exact numbers as I compare the two BOE's back and forth.
Thanks so much for getting us to this point Tracy, and for all your help. Because it's complex (to me), layered programming, we simply·can't do all the programming in the limited time we have. ad too thin and we meet too infrequently. Three Rocketeers are on campuses right now, studying various courses, and the others are scattered about. So I genuinely appreciated it when you share your time and expertise with the kids and I. Thank you! Slowly, I'm learning too/
I'll check in later with updates. The sun is finally out here in New Hampshire (after 3 weeks of rain!) and so I think I'll move outside to and enjoy the vitamin D as I work.
Great, the sun is coming out here too, dissipating the chilling high fog layer that usually comes in over the San Francisco bay and usually lingers until later in the day. Rain during the summer is extremely rare here, as rare as the hailstorm they had in NYC last week.
I'm happy to hear that the program is working, at least in outline. Please do check on the disk file, and those altitude readings too.
The MAWD_get routine converts the string that comes in from the MAWD into a 16 bit integer, stored in the VARiable "feet". I think the conversion from string to integer is correct, but you can also insert a DEBUG statement to display the string as it comes from the MAWD, as follows:
MAWD_get:
' feet=12345 ' use this dummy value and RETURN for testing
' RETURN
PULSIN MAWDin,1,iobyte ' the purpose of this is to synchronize with the MAWD timing.
PAUSE 10 ' this assures the SERIN will start listening in the silent period before a MAWD xmission
feet=0
SERIN MAWDin,84,64,MAWDnot,[noparse][[/noparse]STR buf0\7]
IF buf0(6)=LF THEN
DEBUG TAB,STR buf0\5 ;<-------------insert this debug statement
FOR index=0 TO 4
feet = feet*10 + buf0(index) ' this converts string to integer
NEXT
ENDIF
MAWDnot:
RETURN
It is very possible a simplified version of this routine would work, one that dispenses with the string buffer. This is an alternative, which takes advantage of the Stamp DEC5 modifier to convert the string directly to an integer. If it works, great, if not, that would be due to the speed at which the MAWD delivers each altitude string.
MAWD_get:
' alternative code to acquire MAWD data, uses DEC5 instead of STR in SERIN
PULSIN MAWDin,1,iobyte ' the purpose of this is to synchronize with the MAWD timing.
PAUSE 10 ' this assures the SERIN will start waiting in the silent period before a MAWD xmission
feet=0
SERIN MAWDin,84,64,MAWDnot,[noparse][[/noparse]DEC5 feet]
MAWDnot:
RETURN
The acquisition of the MAWD reading will take from 0.06 to 0.11 second in either of the above two routines, depending on where in the MAWD cycle the Stamp happens to make the call.
· This is Chris. I'm one of the ARLISS NH Rocketeers. Are you suggesting that we replace the·first·'MAWD_get' subroutine that you wrote,·as part MAWDBOE_July10ta.bs2, with the two that you've attached (one at a time, of course) to see what happens? It was exciting to see·altitude data reading out of the MAWD onto the Datalogger this morning. Thank you so much for your help. I'm learning a lot.
I don't want to confuse the issue, but if you have time, you can try the variations that I suggested. You can learn a lot by trying different approaches to the same goal, but that only helps if you dig in and understand how they work and also experiment with variations of your own. But if you find one that works reliably, and you have other tasks to do, like mowing the lawn, or cleaning up your room (?!), or even other things to do with the rocketry project, then don't let playing around with a couple of alternate subroutines stand in the way of those other pressing tasks!
The first variation is the same as the original, except that it adds one simple DEBUG statement. The purpose of that is to verify that the number string that is sent out by the MAWD is the same as the number after it is converted to an integer.
Aha! thank you Chris. While typing this, I suddenly realized that there is a bug in the computation that would account for the differences that you saw when you tried it out earlier.
This statement:
feet = feet*10 + buf0(index) ' this converts string to integer IMPROPERLY!!!!
should be revised to the following:
feet = feet*10 + (buf0(index) - 48) ' this converts ASCII string to integer
My bad. A trap I've fallen into more that once, and one that my connection to the fake MAWD did not reveal. ASCII for the numerals 0 to 9 is the codes 48 to 57. So the conversion math MUST subtract that offset of 48. Please experiment with that line in the program, and learn by seeing the why of it.
The second alternative routine I posted above would not have that problem (provided the timing is okay). In the second routine, the DEC5 modifier handles the conversion directly from ASCII to the Stamp's internal 16 bit integer.
Thanks for the help. I'll give those two a shot, including your most recent change. Functionally there should be no difference in the two, correct? I'll "dig in" and examine the two a little more closely. All of the ARLISS rocketeers are getting together tommorow, so we'll have a few minds to interpret the different solutions.
feet = feet*10 + (buf0(index) - 48)···· and the altitude is a lot more realistic now. It seems to match the altitude the 'bare' BOE generates when we run·the first·'simple altitude program.' I'll have three of the Rocketeers confirm this at tomorow's practice.
So what exactly does putting·a command inside (parentheses) <---- like this, do? The change seems so subtle, yet significant. Its this subtle programming inuendo that seems to take a while to master....!
Christopher and I twiddled around with the 'SERIN' command and the 'vbaud' values to see if we could get faster data output, with mixed results (we slowed it down!)·Currently it reads and·records·data every five seconds. The other day we had the BOE churningout temperature and humidity data twice per second. But as you said in your reply to Christopher, "if it works, no need to fix it~!" (*Unfortunatey he wasn't distracted by mowing the yard or cleaning his room, but thanks for trying...!)
Tomorrow at practice we'll split into three sub-system·teams: one team will work on the programming (cut and paste the two different MAWD subroutines to see what happens); one will figure out how big the parachute needs to be (using descent calculation software); the third will mount the BOE and the MAWD on the ASP platform. I wish you were here to work with us; I'm sure your presence and input would add lots to our practice.
We'll check back in tomorrow; thanks ever so much!
There is a CONstant that determines how often the system acquires data, and right now it is set for 5 seconds. If you want it to be say 2 seconds then change that number to 2.
'
[noparse][[/noparse] Constants ]
' ... other constants ...
logInterval CON 5 ' choose 1,2,3,4,5,6,10,12,15,20,30 seconds
The numbers 1,2,3,4,5,6,10,12,15,20,30 all divide evenly into 60 seconds. I science it is often preferable to acquire data at regular intervals by the clock.
The math for altitude is not just a matter of parentheses. There is also the subtraction of 48 inside the parens that I had missed before. That is the important thing. The parens just tell the BS2 the order it needs to do the calculations.
feet = feet*10 + (buf0(index) - 48)
take the current value of feet, and multiply it times 10
add to that (the Nth ascii digit of the altitude, minus 48)
I said this morning that "Rain during the summer is extremely rare here", but I spoke too soon. We had a rain shower upon us and to the east of us, just at sunset, with the sun to the west over the Golden Gate bridge. That in itself is very unusual in the San Francisco area, but there was also a fabulous double rainbow to the east and colorful clouds to top it off.
·· We had a really fun and productive practice on Sunday. Virtually all the Rocketeers were here, taking a hiatus from their summer programs, and lots was accomplished. First, the MAWD-BOE program seems to be working quite well. Thomas and Christopher, our "electrical engineer" subsystem team,·experimented with·the program code·and modified some of the commands to see what they could get it to do. First they changed the CONstant from 5 to 1 so they could get faster data capture; then they cut-and-pasted each of the MAWD_get subroutines to see what they do. They learned that, while CON 5 gives a five second data transfer rate and CON 1 gives a one second rate, CON 0.5 and CON 1/2 effectively stop the program. My reply was, "I wonder why that is...?" It was great to see Christopher poring over the Parallax website and forums last night, then fall asleep reading "What's a Microcontroller?" It was good teaching and good learning. Thank you.
·· Mollie and Jessica, our "mechanical engineer" subsystem team, worked on how and where to physically mount all the hardware so that everything is accesible (the serial input for example) and protected, and so there' room for the parachute, batteries, etc. We'll start mounting everything this week so we have it for next Sunday's practice. Tyler and Sean, our "physicists" did descent rate calculations to see what size parachute·they need·for a nominal (3-5 m/sec) descent rate. This determines the space needed by our mechanical engineers, and it establishes a maximum payload weight.
Right now the MAWDBOE reads and writes temperature time, humidity, and altitude every second predictably (file attached). The Datalogger "syncs" predicably at 1, 2 or 3, and the disk writes at "1" every time. Thomas and Christopher also "reversed" the boot-up sequence to simulate what will actually happen in flight. The MAWD will·activate with the GEE forces at lift-off so it will be sending data before the BOE is activated at apogee. When they turned the hardware in in this sequence (MAWD, wait 15 seconds, then BOE), the altitude data capture and the BOE data stream were perfect...! Success, thanks again to you.
We'll continue fine-tuning things but, as you said, "If it works, no need to fix it (or if you have a room to clean or a yard to mow, etc.!) I'm curious to see if they'll figure out how to get a faster data read-rate, etc. These are clever kids and we've captured their imagaination.
The double rainbow and colored clouds above the rainbows·sounds bucolic. I didn't know that it doesn't typically rain in SF in the summer. I've never been there, only to southern California years ago. We've certainly had our more-than-fair share of rain this summer. It's only been within the last few days that we've seen sunlight, so we're enjoying our first few days of 'real' summer.
I'll check back in later on. There was an excellent article in the month's 'Extreme Rocketry' magazine that I want to post for you and Sylvie. A group built a modified Parallax BOE-bot with treads, launched it way up in a rocket, then landed and deployed the robot from the rocket. THEN, the robot navigated a mile back to the launch site by GPS. Now THAT'S up our alley, especially since it was launched at Black Rock desert where we'll be launching. Have a...
I'll check back in later on. There was an excellent article in the month's 'Extreme Rocketry' magazine that I want to post for you and Sylvie. A group built a modified Parallax BOE-bot with treads, launched it way up in a rocket, then landed and deployed the robot from the rocket. THEN, the robot navigated a mile back to the launch site by GPS. Now THAT'S up our alley, especially since it was launched at Black Rock desert where we'll be launching. Have a..
I'll have to go get a copy tomorrow, if I get a chance. There was a contest here last year for college students to fly and land a robot, with the prize going to the group whose robot traveled the furthest straight-line distance from their rocket's landing point. None of the teams had a successful flight. About half of them simply crashed, and the rest had various issues with their robots.
That's great news about how the "MAWD-BOE" is going. I'm very excited to hear you've got it working. Again, this is a very sophisticated thing you're doing - none of the rocketeers around here other than the Mad West team have anything remotely that complex going (though the old University School of Milwaukee group trumped us all).
First of all, thanks for all your help. They beat me to it, but Tom and I would indeed like to learn about making the read rate faster. As they said, we tried both fractions and decimals. A lot of the other pbasic programs I have seen use milliseconds. Is this where the solution lies? How does the board know when to interpret the command as seconds or milliseconds?
Thanks again,
Chris (I'll get my own account going soon)
That's good thinking, Chris, and an excellent question.
I suggest that you bring up the Stamp Editor program, and go into the help file. Look at the commands PAUSE, PULSIN, PWM and FREQOUT.
As for the question about fractions and decimals, take a look at the help file's section marked PBasic Operators. Also take a look at the section on memory and variables, where you'll see this:
PBasic Help file author said...
For the BS2-family, the Size argument has four choices: 1) Bit (1 bit), 2) Nib (nibble; 4 bits), 3) Byte (8 bits), and 4) Word (16 bits). Here are some examples of variable declarations on the BS2-family:
mouse VAR Bit ' Value can be 0 or 1cat VAR Nib ' Value can be 0 to 15dog VAR Byte ' Value can be 0 to 255rhino VAR Word ' Value can be 0 to 65535
The example above will create a bit-sized variable called mouse, and nibble-sized variable called cat, a byte-size variable called dog and a word-sized variable called rhino. Unlike in the BS1, these variable declarations don't point to a specific location in RAM. Instead, we only specified the desired size for each variable; the BASIC Stamp will arrange them in RAM as it sees fit. Throughout the rest of the program, we can use the names mouse, cat, dog and rhino to set or retrieve the contents of these variables.
A variable should be given the smallest size that will hold the largest value that will ever be stored in it. If you need a variable to hold the on/off status (1 or 0) of switch, use a bit. If you need a counter for a FOR...NEXT loop that will count from 1 to 100, use a byte. And so on.
If you assign a value to a variable that exceeds its size, the excess bits will be lost. For example, suppose you use the nibble variable cat, from the example above, and write cat = 260 (%100000100 binary). What will cat contain? It will hold only the lowest 4 bits of 260: %0100 (4 decimal)
When you understand this stuff, you're on the road to really understanding microprocessors.
=================================
This is an exciting time for those of us who remember the Apollo missions. Forty years ago we were eagerly awaiting the launch of Apollo 11, the first manned flight to the moon. It launched on July 16th, 1969. Here's a site that will give you an idea what it was like:
http://wechoosethemoon.org/
=================================
I'm still working on that XBee telemetry transmitter thing, trying to get it working with a Propeller instead of a Stamp on the receiver end. I had a breakthrough this morning, and I think I'll have it going very soon, but unfortunately, as usual, real life responsibilities are going to keep me from it probably for the rest of the day. The breakthrough was that I realized I'd set up the XBee to only send transmissions·to one particular other XBee, rather than in "broadcast mode", which allows it to be received by any XBee in range. I changed the setting and everything worked fine. Now I have to program the Propeller.
Since we discussed it in this thread, I decided last week to pull out that radio-controlled deployment rocket, replace the batteries and mount a MAWD in it for backup, and see if it all still works. It does, so weather permitting, I'm going to fly it on Saturday or Sunday, on a K805 Mojave Green motor, using the radio control to deploy the parachute. I also have a boosted dart rocket that I hope to fly. It will carry a small 433 MHz radio transmitter for tracking. Lots of rockets and radios going on over here these days.
This is Tyler, a student working on ARLISS NH. I have a deployment related question for you. At our Sunday meeting, we discussed whether we wanted the parachute to come out before our satellite or after it when the rocket was descending. One suggestion has been to use a parachute bag placed in between the nose cone and the satellite so the parachute bag would come out prior to the satellite. We have previously used a "satellite first" deployment in which the contents of our payload were ejected from the rocket with the parachute behind it. Which deployment system would you recommend: parachute (in bag) first or satellite first?
Thank you Tracy and Sylvie for all your help and support of our project.
Comments
I'm off for a couple of days to play folk music at a hootenanny tonight, then celebrate the 4th with my girlfriend away from the madness that we get here on the Milwaukee lakefront. It's the closing weekend of Summerfest, with the big fireworks display tonight, and I'd rather be elsewhere.
Here (attached) is my idea of fun fireworks. It's the upper half of the rocket I flew with radio-controlled deployment a couple of years ago, and the motor casing for the "K" class motors it flies on. I've got a K805 Mojave Green to fly it on in a couple of weeks, if the weather cooperates. 15 pounds, about 8' 4" tall, carries a MAWD altimeter and a Missileworks WRC digital radio receiver. It has flown 6 times, all on K motors (K550, K695).
I spent an hour or so this morning trying to get my MAWD setup to work with a Propeller. I made some progress, as I can get the Prop to reliably send data to Excel, but I'm not reading the XBee data yet. It just needs more time. One thing that I like about projects like this is that in the process you inevitably learn some things you're going to need later. I'd never used PLX-DAQ with a Prop - it turns out it's incredibly easy.
·· Cool rocket! And it's 8-1/2 feet tall and it flies on a 'K' motor? What kind of altitude do you get? Is it 6" diameter like the ARLISS rocket?
I'm curious how a "radio-controlled deployment" works. I've considered this idea before (but my garage door opener deesn't quite have the transmit distance.) Is it a remote-controlled deployment system,like a remote-controlled airplane? What happens if the rocket is out of range, or if you can't see·the rocket·to determine when to deploy (or if the batteries aren't strong enough, etc.)? Is there a back-up deployment system?
So what instrument do you play at the hootenanny? A fiddle? A guitar? I envy people who are musically talented (like my wife and son.) I couldn't play a note to save myself.
Looks like Tracy is a having a fun-filled 4th of July, too. He's at a place called Half Moon Bay (sounds bucolic) to
>·
maybe see the highly unofficial and tenuously illegal fireworks displays individuals shoot off on many of the small beaches in Santa Cruz. Some of these people have serious skyrockets. Fun, close up, and slightly dangerous, like old times.
Now you're talking our langauge, Tracy! Have fun, and be safe.
Regards from the coast of Maine,
Mark
The rocket is made from 5.5" diameter LOC, and it's built like a tank (fiberglass/epoxy), so it makes only about 2800' on a K 550. On the K805 it should barely crack 3000'.
The radio control unit I used in it is a now-discontinued Missileworks WRC. It's a very big unit - I don't think it'd fit into anything smaller than 5.5" tubing - and requires an 11-14VDC onboard power supply (I'm using a 9V battery in series with two AA cells). It operates in the 900 MHz range, spread spectrum, and uses digital codes to safeguard against accidental firing. The radio range is good - it fired reliably each time that I used it (though the first unit I received only worked if the transmitter was right next to the receiver - it was defective, and readily replaced by the maker). It's really fun to be standing on the ground watching your rocket coming in, and push a button to deploy the main parachute. I don't know what it would take to be out of range, but you'd surely be out of sight before that.
I did use a MAWD as backup. Actually, I let the MAWD fire the apogee charge, with a backup charge for that wired to the radio control (so the radio control backed up the altimeter for the apogee charge). Then the MAWD was set to fire the main at a relatively low altitude as backup for the radio control. I never needed the backups - in fact, I've never had a charge fail to fire in any of my rocket flights. These things are pretty reliable if you know your devices and take care in wiring things. I've also flown that same rocket with two MAWDs, one set to fire at apogee, the other a second later, and then one set to deploy the main at 700 feet, with the other backing that up at 500 feet (or maybe it was 900' and 700' - I don't remember). Again, worked perfectly.
I did fire the backup apogee charges after all of the other charges had fired. It's important NOT to land with live charges in your rocket, for fairly obvious reasons. I waited until after all of the other events had happened because I didn't want to risk the backup apogee charge knocking the main chute out before I was at low altitude. It was really interesting to set up those events and work my way through the checklist during flight.
The WRC was expensive and huge, as I mentioned, and you could surely build a reliable one that was much smaller and at least a little cheaper using XBee 900 MHz radios, maybe a Stamp onboard (though it might be possible to do without, but that's beyond my ability), and a simple firing circuit. Word is that the Missileworks guy (Jim Amos) is working on a smaller replacement system.
My name is Jessica and I am on Mark Kibler's ARLISS team. You said for the radio control to be out of range we'd have to be out of sight. We were pretty much expecting to be out of sight of the rocket after it's launched. How would we know when to press the button?
The project I was using this radio on was one for which we wanted to open a parachute at a certain point. The rocket had come back down into our visual range by the time we needed to open the parachute. If you needed to signal the rocket at a certain time while it was still out of sight, you'd need some kind of indicator of the right time. What you used would depend on the project.
·
Just wondering here, would it be possible for us to use a radio control with our project? Also,·are you suggesting that we should use·a radio control·or not?
·
Thank you for your time and help,
·
Sean from ARLISS-NH
No, I'm not suggesting radio control for your project. Just ignore me. Sorry about the confusion.
·· Thanks for answering the kids' question. Keep in mind that most of this·is brand new to literally half the team, and the techno-speak that you, Tracy and I toss back and forth easily might seem like Greek to them. A pat on the back to each of these young Rocketeers·for daring to ask the questions! Two pats on the back-- to you and Tracy-- for answering them, and for helping us figure out the programming (which·is like Greek to me half the time!) Thanks. You're teaching and inspiring some bright young minds.
Jess,··
·You asked a great question ·
1) "Line of sight"·refes·to radio·wave·transmission. If·a radio wave receiver·(our 'Beast-finder') is strong enough-- and if there is nothing between the rocket's transmitter·and the receiver-- you should be able to receive a signal even though you can't see the rocket. The radio wave follows an invisible, make-believe "line of sight" between the transmitter and receiver, even if they're 20 miles apart. If you block the signal (the 'line of sight') with a hill, a forest, even a large cluster of trees or a building, the radio wave is blocked and the signal·may not·get through.
2) 'Visibility' means that you have a clear 'line of sight' to the object. You can see it until it disappears which, like you said, our rocket definitely will do. But just because we can't see the rocket doesn't mean that it doesn't have "line of sight" radio transmission. The rocket is·certainly up there somewhere--in a direct line with us on the ground--but we can't see it because it's up too high. That's why we·need a transmitter: to find it. That's why we want a transmitter with the greatest signal strength: to increase it's line of sight distance, so we don;tlose everything.
Great question Jess!
Sean,
· You asked another good question
I'll see you Rocketeers this Sunday for practice. Keep reading the forum and asking questions. This is how you learn. The information we glean this we, we'll need to apply on Sunday...!! I'll look for more of your questions and commenst on the forum.
Bravo, Sean!
Aim high,
Mr. Kibler
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
·· You're absolutely right: seemingly 'off-topic' questions and·discussion often lead to directly relevant insights, sometimes emphatically not. It is a very useful skill to be able to separate the core issues from the sidetracks.
There's a·beauty and a synergy here. Sometimes these off-topic questions and ideas lead to new discoveries and inventions! It's the difference between being good end-users of current technology, or·developers of future technology. 1+1+1 sometimes does equal 4, even 5. That's synergy, and that's what we're all about.
How was Half Moon Bay?
Mark
Ah, excellent point. In my experience, it's always good to have explored what's possible, even when you don't need it at the moment. Then later when a new problem arises, you just might already have the solution in hand.
I have a whole bunch of devices sitting around here that I've never put to any real use, but I did play around with them enough to get 'em working when I got 'em. That is, in fact, how I knew how to communicate with the MAWD back over a year ago.
The dog is a Gordon Setter, a truly huge breed. We took him to the parade earlier in the day. It was so big it turned heads and made small children run for their mothers, but the dog is really an emotional pushover, but physically you don't want him to lean on you. The parade in Watsonville was interesting with a heavily Mexican American influence, with Mariachi Bandas, farm machinery, pimped up cars, and hundreds of fancy prancing horses. The following day we passed through a small town where the local volunteer fire department had their annual pancake breakfast, and it is always fun to get in on a local event like that. And then we worked off the pancakes with a hike in the redwoods. A great and relaxing time overall.
Back to topic. Sometime back I think Mark mentioned that he had acquired a methane sensor from Parallax. I don't recall if there was any thought of using that in the rocketeers' ASP. Methane is one of the heat trapping gases that along with CO2 has increased considerably in the upper atmosphere in the past couple of centuries. I would leave it as a problem for a rocketeer, what is the situation with methane in the atmosphere, and would the sensor be capable of detecting anything useful?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
···· The pancake breakfast and a hike through the woods sounds like a nice trade-off to traditional fireworks (especially if they would excite a house-sized dog! How big is your dog anyway? The size of a Great Pyrenees or a St. Bernard?)
We did acquire a Parallax methane sensor but we have no plans for using it on the ASP right now. We have to get the MAWD wiring and programming firmed up first (and there's no room on the curent BOE-ASP circuit board. The modular methane sensor requires 4 open pins and more space than we have available.) Maybe we could add it as a "stand-alone" sensor on another BOE board once we get the ASP fully functional. Maybe.
So where do we go with programming the MAWD-BOE from here? I tried cutting-and-pasting the MAWD program you wrote earlier into the "ASP" (robot) program without much success...
Mark
I assume that when you posted the MAWD program into the ASP (robot) program that you made the MAWD program a subroutine of the ASP (robot) program. Now, in the ASP (robot) program, there is already a subroutine to record the data to the data logger. What we need to do is copy and paste the MAWD program into the ASP (robot) program (like you already did) and determine the point in the program where the MAWD subroutine should be initiated. We·also need to·figure out if there are any duplicate details in the two programs (possibly recording on the data logger) and merge the programs together.
·
Hello from Terrorism camp,
·
Tyler Becker
·
·
P.S. My class is called International Terrorism and Political Violence for everyone else reading this thread.
·
P.S.S. I like the patches. Nice job Mr. Kibler!
Post Edited (Tyler from ARLISS NH) : 7/9/2009 11:45:44 PM GMT
··· I'm glad to hear that you're enjoying the St. Pauls' Advanced Study Program ("terrorism school" as you so eloquently call it!) I just got an e-mail from Andrew and he reports that he's having a super time at Phillips-Exeter's Math, Science and Technology program (I'm not sure what interesting nickname he has for it... yet!) They call him, appropriately,·"the kid from NASA." Have you seen Mollie at St. Paul's? She's studying German, right?
You're on target with your suggestions and insights. Theoretically the MAWD program·should be imbedded into the ASP program as a subroutine: "...copy and paste the MAWD program into the ASP (robot) program and determine the point in the program where the MAWD subroutine should be initiated." Practially though, I haven't got it to work... yet.·Here's where we need to ask for and rely on expert help.·I·tried cutting-and-pasting Mr. Allen's··MAWD subroutine into the ASP program, with curious but unsuccessful results.·First it caused the Datalogger to record temperature and humidity twice as fast (a good thing actually.) Another time the Datalogger "sped up" while the MAWD was running in the vacuum chamber; then it slowed down to "normal" speed when the MAWD reached 1 ATM (1 atmospheric pressure, or 62.4 lbs/in2.) But I never did get it to write·altitude data to the Datalogger.·So I'm a bit miffed-- stumped-- puzzled-- boggled--- but it's fun trying! I also read the book, which I'm slowly understanding. For now, though, I'll defer to Mr. Allen, and hope the he can help us out the programming as he did last year.
I'm glad you like the mission patch. They were designed and made with help from "your friends at NASA." It's amazing just how many friends you guys (and gals) have, and how your success follows you far and wide. Keep up the good work Tyler, and have fun at St. Paul's. And make lots of new friends...! Thanks for checking in on the forum. I'll see you on Sunday at 1 PM.
Aim high,
Mr. Kibler
This adds support for the MAWD, in terms of capturing the altitude data and storing it in the log file. Each record in the log file is now 29 bytes with the added 5 digit altitude field and a comma. Also, it synchronizes the data logging to the clock, so that it scans at exactly 5 second intervals, or whatever number you enter in the CONstant "logInterval".
I am using a MAWD simulator made from another BASIC Stamp, which sends out a fake altitude string at 50 millisecond intervals. I don't have a real MAWD. So there may well be some issues there. I have it assigned to pin p3, but of course you can change that.
MAWDin PIN 3
I used altered wiring to the Stamp for the DS1302, that being Stamp pins p7, p6, and p5 instead of p2, p5 and p7. There are a couple of reasons that I did that, and I was going to change it back, but forgot until just now. You should change those pin definitions back to match what exists on your BOE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
· We (Christopher and I) downloaded and tried your new·program this morning and it works well! When we put the MAWD in the vacuum chamber the altitude data read out on the screen along with temperature, humidity, and time (in my excitement I didn't remove the flash drive to see the data file, but I'm sure it's there.) After we changed pins 7, 6,and 5 back to 2, 5 and 7·like you suggested, it also showed elapsed time. This is a major milestone, and an excellent starting point for tomorrow's "all team" practice.
One observation that I'll explore more today is the fact that·the altitude on the new program appears to read "high." For example, when I run your first 'simple' altitude program on a bare BOE, the altitude reaches approximately 7,000 pressure altitude feet when the vacuum pump·is drawing·200 psi. On the new MAWDBOE_July10ta.bs2··program, it's more than double that. I'll re-test this afternoon and get you some more exact numbers as I compare the two BOE's back and forth.
Thanks so much for getting us to this point Tracy, and for all your help. Because it's complex (to me), layered programming, we simply·can't do all the programming in the limited time we have. ad too thin and we meet too infrequently. Three Rocketeers are on campuses right now, studying various courses, and the others are scattered about. So I genuinely appreciated it when you share your time and expertise with the kids and I. Thank you! Slowly, I'm learning too/
I'll check in later with updates. The sun is finally out here in New Hampshire (after 3 weeks of rain!) and so I think I'll move outside to and enjoy the vitamin D as I work.
More later,
Mark
I'm happy to hear that the program is working, at least in outline. Please do check on the disk file, and those altitude readings too.
The MAWD_get routine converts the string that comes in from the MAWD into a 16 bit integer, stored in the VARiable "feet". I think the conversion from string to integer is correct, but you can also insert a DEBUG statement to display the string as it comes from the MAWD, as follows:
MAWD_get: ' feet=12345 ' use this dummy value and RETURN for testing ' RETURN PULSIN MAWDin,1,iobyte ' the purpose of this is to synchronize with the MAWD timing. PAUSE 10 ' this assures the SERIN will start listening in the silent period before a MAWD xmission feet=0 SERIN MAWDin,84,64,MAWDnot,[noparse][[/noparse]STR buf0\7] IF buf0(6)=LF THEN DEBUG TAB,STR buf0\5 ;<-------------insert this debug statement FOR index=0 TO 4 feet = feet*10 + buf0(index) ' this converts string to integer NEXT ENDIF MAWDnot: RETURNIt is very possible a simplified version of this routine would work, one that dispenses with the string buffer. This is an alternative, which takes advantage of the Stamp DEC5 modifier to convert the string directly to an integer. If it works, great, if not, that would be due to the speed at which the MAWD delivers each altitude string.
The acquisition of the MAWD reading will take from 0.06 to 0.11 second in either of the above two routines, depending on where in the MAWD cycle the Stamp happens to make the call.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
· This is Chris. I'm one of the ARLISS NH Rocketeers. Are you suggesting that we replace the·first·'MAWD_get' subroutine that you wrote,·as part MAWDBOE_July10ta.bs2, with the two that you've attached (one at a time, of course) to see what happens? It was exciting to see·altitude data reading out of the MAWD onto the Datalogger this morning. Thank you so much for your help. I'm learning a lot.
Chris (Kibler)
I don't want to confuse the issue, but if you have time, you can try the variations that I suggested. You can learn a lot by trying different approaches to the same goal, but that only helps if you dig in and understand how they work and also experiment with variations of your own. But if you find one that works reliably, and you have other tasks to do, like mowing the lawn, or cleaning up your room (?!), or even other things to do with the rocketry project, then don't let playing around with a couple of alternate subroutines stand in the way of those other pressing tasks!
The first variation is the same as the original, except that it adds one simple DEBUG statement. The purpose of that is to verify that the number string that is sent out by the MAWD is the same as the number after it is converted to an integer.
Aha! thank you Chris. While typing this, I suddenly realized that there is a bug in the computation that would account for the differences that you saw when you tried it out earlier.
This statement:
feet = feet*10 + buf0(index) ' this converts string to integer IMPROPERLY!!!!
should be revised to the following:
feet = feet*10 + (buf0(index) - 48) ' this converts ASCII string to integer
My bad. A trap I've fallen into more that once, and one that my connection to the fake MAWD did not reveal. ASCII for the numerals 0 to 9 is the codes 48 to 57. So the conversion math MUST subtract that offset of 48. Please experiment with that line in the program, and learn by seeing the why of it.
The second alternative routine I posted above would not have that problem (provided the timing is okay). In the second routine, the DEC5 modifier handles the conversion directly from ASCII to the Stamp's internal 16 bit integer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Thanks for the help. I'll give those two a shot, including your most recent change. Functionally there should be no difference in the two, correct? I'll "dig in" and examine the two a little more closely. All of the ARLISS rocketeers are getting together tommorow, so we'll have a few minds to interpret the different solutions.
Thanks again,
Chris
·· We revised the
feet = feet*10 + buf0(index)···· command to read:
feet = feet*10 + (buf0(index) - 48)···· and the altitude is a lot more realistic now. It seems to match the altitude the 'bare' BOE generates when we run·the first·'simple altitude program.' I'll have three of the Rocketeers confirm this at tomorow's practice.
So what exactly does putting·a command inside (parentheses) <---- like this, do? The change seems so subtle, yet significant. Its this subtle programming inuendo that seems to take a while to master....!
Christopher and I twiddled around with the 'SERIN' command and the 'vbaud' values to see if we could get faster data output, with mixed results (we slowed it down!)·Currently it reads and·records·data every five seconds. The other day we had the BOE churningout temperature and humidity data twice per second. But as you said in your reply to Christopher, "if it works, no need to fix it~!" (*Unfortunatey he wasn't distracted by mowing the yard or cleaning his room, but thanks for trying...!)
Tomorrow at practice we'll split into three sub-system·teams: one team will work on the programming (cut and paste the two different MAWD subroutines to see what happens); one will figure out how big the parachute needs to be (using descent calculation software); the third will mount the BOE and the MAWD on the ASP platform. I wish you were here to work with us; I'm sure your presence and input would add lots to our practice.
We'll check back in tomorrow; thanks ever so much!
Mark
'
[noparse][[/noparse] Constants ]
' ... other constants ...
logInterval CON 5 ' choose 1,2,3,4,5,6,10,12,15,20,30 seconds
The numbers 1,2,3,4,5,6,10,12,15,20,30 all divide evenly into 60 seconds. I science it is often preferable to acquire data at regular intervals by the clock.
The math for altitude is not just a matter of parentheses. There is also the subtraction of 48 inside the parens that I had missed before. That is the important thing. The parens just tell the BS2 the order it needs to do the calculations.
feet = feet*10 + (buf0(index) - 48)
take the current value of feet, and multiply it times 10
add to that (the Nth ascii digit of the altitude, minus 48)
I said this morning that "Rain during the summer is extremely rare here", but I spoke too soon. We had a rain shower upon us and to the east of us, just at sunset, with the sun to the west over the Golden Gate bridge. That in itself is very unusual in the San Francisco area, but there was also a fabulous double rainbow to the east and colorful clouds to top it off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
·· We had a really fun and productive practice on Sunday. Virtually all the Rocketeers were here, taking a hiatus from their summer programs, and lots was accomplished. First, the MAWD-BOE program seems to be working quite well. Thomas and Christopher, our "electrical engineer" subsystem team,·experimented with·the program code·and modified some of the commands to see what they could get it to do. First they changed the CONstant from 5 to 1 so they could get faster data capture; then they cut-and-pasted each of the MAWD_get subroutines to see what they do. They learned that, while CON 5 gives a five second data transfer rate and CON 1 gives a one second rate, CON 0.5 and CON 1/2 effectively stop the program. My reply was, "I wonder why that is...?" It was great to see Christopher poring over the Parallax website and forums last night, then fall asleep reading "What's a Microcontroller?" It was good teaching and good learning. Thank you.
·· Mollie and Jessica, our "mechanical engineer" subsystem team, worked on how and where to physically mount all the hardware so that everything is accesible (the serial input for example) and protected, and so there' room for the parachute, batteries, etc. We'll start mounting everything this week so we have it for next Sunday's practice. Tyler and Sean, our "physicists" did descent rate calculations to see what size parachute·they need·for a nominal (3-5 m/sec) descent rate. This determines the space needed by our mechanical engineers, and it establishes a maximum payload weight.
Right now the MAWDBOE reads and writes temperature time, humidity, and altitude every second predictably (file attached). The Datalogger "syncs" predicably at 1, 2 or 3, and the disk writes at "1" every time. Thomas and Christopher also "reversed" the boot-up sequence to simulate what will actually happen in flight. The MAWD will·activate with the GEE forces at lift-off so it will be sending data before the BOE is activated at apogee. When they turned the hardware in in this sequence (MAWD, wait 15 seconds, then BOE), the altitude data capture and the BOE data stream were perfect...! Success, thanks again to you.
We'll continue fine-tuning things but, as you said, "If it works, no need to fix it (or if you have a room to clean or a yard to mow, etc.!) I'm curious to see if they'll figure out how to get a faster data read-rate, etc. These are clever kids and we've captured their imagaination.
The double rainbow and colored clouds above the rainbows·sounds bucolic. I didn't know that it doesn't typically rain in SF in the summer. I've never been there, only to southern California years ago. We've certainly had our more-than-fair share of rain this summer. It's only been within the last few days that we've seen sunlight, so we're enjoying our first few days of 'real' summer.
I'll check back in later on. There was an excellent article in the month's 'Extreme Rocketry' magazine that I want to post for you and Sylvie. A group built a modified Parallax BOE-bot with treads, launched it way up in a rocket, then landed and deployed the robot from the rocket. THEN, the robot navigated a mile back to the launch site by GPS. Now THAT'S up our alley, especially since it was launched at Black Rock desert where we'll be launching. Have a...
Good morning,
Mark
Thomas & Christopher, do you want an explanation of why 0.5 and 1/2 don't work, or are you figuring it out already?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I would like an explanation on why 1/2 and .5 don't work. Also is there a way to get data faster than CON 1?
Thank you for your help with the programming,
Tom
That's great news about how the "MAWD-BOE" is going. I'm very excited to hear you've got it working. Again, this is a very sophisticated thing you're doing - none of the rocketeers around here other than the Mad West team have anything remotely that complex going (though the old University School of Milwaukee group trumped us all).
First of all, thanks for all your help. They beat me to it, but Tom and I would indeed like to learn about making the read rate faster. As they said, we tried both fractions and decimals. A lot of the other pbasic programs I have seen use milliseconds. Is this where the solution lies? How does the board know when to interpret the command as seconds or milliseconds?
Thanks again,
Chris (I'll get my own account going soon)
I suggest that you bring up the Stamp Editor program, and go into the help file. Look at the commands PAUSE, PULSIN, PWM and FREQOUT.
As for the question about fractions and decimals, take a look at the help file's section marked PBasic Operators. Also take a look at the section on memory and variables, where you'll see this:
When you understand this stuff, you're on the road to really understanding microprocessors.
=================================
This is an exciting time for those of us who remember the Apollo missions. Forty years ago we were eagerly awaiting the launch of Apollo 11, the first manned flight to the moon. It launched on July 16th, 1969. Here's a site that will give you an idea what it was like:
http://wechoosethemoon.org/
=================================
I'm still working on that XBee telemetry transmitter thing, trying to get it working with a Propeller instead of a Stamp on the receiver end. I had a breakthrough this morning, and I think I'll have it going very soon, but unfortunately, as usual, real life responsibilities are going to keep me from it probably for the rest of the day. The breakthrough was that I realized I'd set up the XBee to only send transmissions·to one particular other XBee, rather than in "broadcast mode", which allows it to be received by any XBee in range. I changed the setting and everything worked fine. Now I have to program the Propeller.
Since we discussed it in this thread, I decided last week to pull out that radio-controlled deployment rocket, replace the batteries and mount a MAWD in it for backup, and see if it all still works. It does, so weather permitting, I'm going to fly it on Saturday or Sunday, on a K805 Mojave Green motor, using the radio control to deploy the parachute. I also have a boosted dart rocket that I hope to fly. It will carry a small 433 MHz radio transmitter for tracking. Lots of rockets and radios going on over here these days.
This is Tyler, a student working on ARLISS NH. I have a deployment related question for you. At our Sunday meeting, we discussed whether we wanted the parachute to come out before our satellite or after it when the rocket was descending. One suggestion has been to use a parachute bag placed in between the nose cone and the satellite so the parachute bag would come out prior to the satellite. We have previously used a "satellite first" deployment in which the contents of our payload were ejected from the rocket with the parachute behind it. Which deployment system would you recommend: parachute (in bag) first or satellite first?
Thank you Tracy and Sylvie for all your help and support of our project.
Tyler from ARLISS NH