Just wondering here, what exactly does·a parachute bag do? I hope this isn't one of those 'duh' answers. · Thank you all for time and help, · Sean from ARLISS-NH
Tyler - I don't know what you're asking, because I don't know what you mean by "satelite". Could you explain that?
Sean - A parachute bag (or more often "deployment bag") is a flameproof bag that the main parachute goes into. It protects the parachute from the ejection charge, and also helps ensure "orderly deployment". A small pilot chute pulls the deployment bag out of the rocket. It pulls the shock cord straight, and then pulls the shroud lines out of the bag. Finally the main chute is pulled out and inflates. Pulling the shock cord and then shroud lines straight before inflating the main chute significantly reduces the stress on the system. It also reduces the chance of things tangling.
I don't usually fly with a deployment bag, but I've been looking into using one more. I have one for my 4" rocket, and flew it a couple of times.
·· The "satellite" is the MAWDBOE/ ASP payload (since the proejct is called the Rocket Launch for International Student Satellites, or ARLISS.)
When the MAWD-BOE deploys, the payload bay and the nose cone will be pointed straight down. The MAWD-BOE is ejected 4-6 seconds after apogee withe nose cone pointing downward. One of the ARLISS guys suggested putting·our parachute under the MAWD-BOE in a parachute bag so the MAWD-BOE pushes the parachute/ bag·out ahead of it. We wonder whether the MAWD-BOE will have so·much ejection force that it basically embeds itself in the parachute (with ·the whole mess just tumbling to the ground, tangled.)
In the past, our payloads have·come out ahead of (above, or behind) the parachute so the parachute·opens·above the payload. If we do it this way, the fellow at ARLISS thinks there will be so much stress force that the parachute will simply tear itself off of the MAWD-BOE/ ASP payload. I think there will be more stress force doing it the other way because the paylaod will have more time to accelerate toward the ground before the parachute comes out of the parachute bag (f·= m x a.) We plan to use a rubber surgical tubing shockline attached Kevlar, attachd, to the parachute... What are your thoughts? Does this make sense?
It's midnight, and the MAWD-BOE is now officially mounted·to the ASP payload module! (I'll send pictures.) Tomorrow we'll permanently wire the MAWD to the BOE the re-test it in the vacuum chamber.·Then we have to start searching for long-lasting power supplies (not just·a 9-volt lithium battery.) We also have to connect the Kevlar shockline and surgical tubing, and ground test the parachute. We've kicked around the idea of using the MAWD's second ejection charge to activate a colored smoke flare at 1,000' AGL, bu that's down the road, only if we have 'extra' time (I can visualize the whole thing catching fire-- in color--·1,000 before it lands!)· But we're moving along (yawn!)
I'm eager to hear more about all the electronics you're testing and launching in your rockets. and where do you have the luxury of launching J and K motors so often (lucky guy!) Thanks for the code you posted for Christopher.He mused over it and did a lot of reading, then started programming. I'm not sure what the outcome was (but I didn't hear "Eureka"!)
**Can I simple cut the other un-used wires off the MAWD's data download cable since only the brown and blue wires are used? I plan to connect them (the blue and brown wires) directly to the BOE'sPIN 15 and Vss.)
·· Let me clarify. I said: In the past, our payloads have·come out ahead of (above, or behind) the parachute so the parachute·opens·above the payload.
What I meant to say was that, in the past, our·payload comes out first and the parachute second (opening above the payload.) The ARLISS guy suggests the opposite: The parachute comes out first, followed by the MAWD-BOE "satellite" (*on top of the parachute.) Will it open...?
Tom ARLISS- NH said...
Mr. Allen
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
Hi Tom,
The Stamp works strictly with integers and does integer math. When it divides 1 by 2, its answer is zero. It takes the whole number result and drops the remainder.
The interval is held in the constant,
logInterval CON 1 ' choose 1,2,3,4,5,6,10,12,15,20,30 seconds
When you enter a 1/2 there instead of 1, the Stamp happily uses its integer math and calculates, logInterval = zero.
When you enter 0.5 there, it will, I think, scream, "syntax error!", because the Stamp does not know what to do with the decimal point.
As it stands, in the MAIN loop, there is a call to a subroutine called "RTC_sync".
GOSUB RTC_sync
What that subroutine does is, it reads the DS1302 clock chip repeatedly, very fast, and it looks for a change in the seconds. That is a change from 1 to 2, or from 2 to 3 and so on up to 59 back to zero. It can't detect anything less than a one second change, because the DS1302 ticks off seconds, no finer than that. If you want to have faster cycling, one way to do it is to replace the above statement in the main loop with this one:
IF logInterval=0 THEN GOSUB RTC_read ELSE GOSUB RTC_sync
That way if you enter zero as the log interval:
logInterval CON 0 ' choose 0,1,2,3,4,5,6,10,12,15,20,30 seconds
the logger will take data as fast as possible, and not try to sync to the tick of the seconds. It will still of course read the DS1302 clock and store the time in your USB log file.
You told me that when you entered 1/2 for the logging interval, the logger just sat there and did nothing. You know now that the Stamp integer math turns that into a zero. But that doesn't explain why it just sat there. (Anyone not interested in why can stop reading.) Here is the RTC_sync subroutine:
rtc_Sync:
' paces data logging to the number of seconds specified in CONstant "logInterval"
buffer=logInterval*200 ' this variable is used as a temporary counter
DO:DO
GOSUB RTC_read
buffer=buffer-1 ' this countdown is an escape from loop in case RTC fails
LOOP UNTIL second<>second0 OR buffer=0 '
second0=second ' change, update old value for tracking
LOOP UNTIL second.NIB1*10+second.NIB0//logInterval=0 OR buffer=0 ' wait for log interval to arrive
' DEBUG CR,?buffer
RETURN
The variable buffer is used here as a simple 16 bit integer (ignore any connotations of the word "buffer"). At the top that is set equal to logInterval*200, so when logInterval=0, the buffer=0. The purpose of that variable is to act as an escape hatch in case the RTC stops working for any reason.
Why would the RTC stop working? Who knows? Maybe the shock of the ejection charge would shake it loose from its socket or maybe crack the delicate timekeeping crystal. I don't really know and I certainly don't think there is danger that that will happen. But if it does happen with some remote probability, it is still desirable for the program to continue taking data, rather than sitting in a DO:LOOP waiting for the second to change, when it never does. This is a part of "failsafe" engineering. Try to anticipate failure modes and bypass them if they occur.
The variable "buffer" counts the number of trys and it can time out if the clock stops, and escape from the subroutine so data logging can continue at intervals. Anyway, if logInterval=0 and buffer=0, then it has to count all the way around from 65535 back to zero, because of the way the loop is set up to subtract buffer-1 for each try. That takes a very very long time, by my calculation, about 350 seconds.
That is why I suggested making zero a special case for logInterval, to mean "as fast as possible". But you can still revert to intervals that sync to the seconds. If you always want to log data as fast as possible, then change the statement in the main loop to
GOSUB RTC_read '<---- read, not sync
Then there is no call to the RTC_sync subroutine and you can delete it and also the logInterval CONstant. By the way, the RTC_read routine will not lock up, even if the clock chip breaks. Both the SHIFTIN and I2CIN commands on the Stamp have a built-in timeouts. If the clock breaks, logging will continue with sample after sample, just without a good timestamp.
edit: meant to say that the SHIFTIN command for the DS1302 has a builtin timeout. The I2CIN command (That I use for the DS1307 RTC on my own loggers) also has a built-in timeout.
·· Let me clarify. I said: In the past, our payloads have·come out ahead of (above, or behind) the parachute so the parachute·opens·above the payload.
What I meant to say was that, in the past, our·payload comes out first and the parachute second (opening above the payload.) The ARLISS guy suggests the opposite: The parachute comes out first, followed by the MAWD-BOE "satellite" (*on top of the parachute.) Will it open...?
Mark
I definitely do not want to present myself as being more expert about this kind of thing than "the ARLISS guy". I'd defer to him.
If your concern is about the payload tangling the shroud lines, that's one of the things that·a deployment bag is meant to avoid. The shroud lines are inside the bag as the bag/chute and the payload go past each other. I guess the lines on the pilot chute could tangle with the payload, but the shroud lines on the pilot chute are quite short, so that's not very likely.
I'm still not quite following what is connected to what. The rocket arcs over. A few seconds after apogee, the apogee charge fires, pushing off the nose cone. I assume that there's a drogue chute of some sort on the rocket itself.
Does your payload (the "satellite") come down entirely separately from the rocket itself?
If so, are you opening a main chute at more than 10,000 feet in the air?
If so, how do you plan to recover the payload?
Or is the satellite still attached to the rocket somehow?
If the satellite does eject completely and come down separately from the rocket, I don't think that it makes that much difference whether the parachute is above or below the satellite while it sits inside the rocket. I assume they're helping you to pack the parachute? The shroud lines should be folded inside of the parachute, so that they're not exposed until the chute is opening, and so that they don't wrap around the chute and prevent it from opening. When it is all ejected, it'll probably flop around so much in the first second or two that by the time the chute opens, it makes no difference whether it was above or below the satellite while inside the rocket.
Will your satellite be the only one inside the rocket? If not, I'd be more concerned about fouling with other things being ejected than I would about the order of parts on my own satellite.
All of that being said, I definitely defer to the ARLISS people, or at least to whichever local expert actually has the whole setup sitting in front of him.
Re. the idea of using a flare, be very careful. I've seen it done, but it has a very high potential for starting a fire. This is a particularly sensitive topic here today:
A flare that some idiot fired up on top of the Patrick Cudahy factory last week·started a major fire that lasted three days, required the attention of several fire departments, required the evacuation of every home in a mile radius, and put quite a few people temporarily out of work. I know there won't be that much chance of anything like that where you're flying, but flares should be treated as dangerous. We don't ever use flares or smoke cannisters on our rockets, because we fly in a prairie (Bong Recreation Area) where (as Pavel found out) there is a very real risk of wild fire. We generally use radio beacons for finding our rockets if they fly very high, or sonic beacons (personal alarms) if they're not going that high. I'll have a Big Red Bee 433 MHz beacon in my boosted dart this weekend.
Re. my having lots of opportunities to fly, I live in a very active area (south eastern Wisconsin), with both NAR and Tripoli clubs. During the summer there are typically two high power launches a month right at Bong, plus others at other fields within a day's drive.
Does your payload (the "satellite") come down entirely separately from the rocket itself?
> YES· (and the nose cone descends on a separate parachute. The payload and booster are on a third 'chute.)
If so, are you opening a main chute at more than 10,000 feet in the air?·····················
> YES. And a big one, too!......... drift --> ?·........................................................................drift --> ??
If so, how do you plan to recover the payload?·······················································
> We're using a Garmin Astro DC 20 dog tracker/ transmitter mounted on the payload. It transmits to a GPS and ································································································································ it has a 5+ mile range. We had access to it so we used it. I would prefer a BigRedBee transmitter, but... $$$
Or is the satellite still attached to the rocket somehow?···········································
> NO
Will your satellite be the only one inside the rocket?·················································
> YES
··· So·when you·use a parachute bag, does it always·use a pilot (drogue?) parachute to pull out the main parachute? This is·a first for me.
··· If we do use a flare, etc: 1) Black Rock is a dry lake bed (so they say); and 2) We'll be sure to consult Pavel!
Christopher was intrigued by the programming suggestions you posted last night and he mused over them for hours. He tried using VAR· 0.0110010 (with a decimal point) and didn't get beyond that point. Now he's·poring over Tracy's latest lesson...! Thanks Tracy [noparse]:)[/noparse]
·If we do use a flare, etc: 1) Black Rock is a dry lake bed (so they say); and 2) We'll be sure to consult Pavel!
LOL. Be sure to take some "Before" pictures, then, because Black Rock won't look the same after.
I understand about the satellite now. I think the Garmin GPS will be the best way you could go for recovery. I guess things are different at Black Rock - here we'd be worrying about being in a tree or a pond or some other inaccessible place.
I do believe that deployment bags always use pilot chutes, but I could be wrong about that. Here is the bag I have, and a link to some instructions for using them:
I'll try that to make the read rate faster. I tried a bunch of different solutions last night, but if the clock chip can't read faster than 1 second intervals, than that explains why they didn't work. I've certainly been learning alot though!
· Thanks for the link to the Quickburst website. I understand the deployment bag idea a bit better now. So the pilot 'chute stays outside of the deployment bag, right? It rests atop the bag and pulls the main 'chute out?
We don't have lots of space·inside the payload bay,·on top of the "satellite", for a large parachute/ apparatus. It will have to be compact.·We have 5.75" diameter to work·with, but only about 4" in height for the parachute.·That's determined by the maximum allowable length (9.75") minus the height of the "satellite" (5.75".)·I'll have to·uplink some·photos now that the MAWD-BOE is mounted on the payload platform (the ASP.)
Visualize two, 5.75" diameter x 1/2" thick bulkheads connected with a 9" piece of 1/2" thick wood. That's the platform the MAWD-BOE is mounted on. The parachute attaches to the upper bulkhead. The nose cone has a bulkhead of its own, which sits atop the parachute.
Attached is a photo that explains why we want the parachute to work well... and what we don't want...~! One of the ARLISS guys sent it to Sean to let us know what could happen if things get ugly at deployment time.
Attached is a photo that explains why we want the parachute to work well... and what we don't want...~! One of the ARLISS guys sent it to Sean to let us know what could happen if things get ugly at deployment time.
We refer to that as "re-kitting".
It looks like the result of a rocket that transitioned to a high density layer of the terrasphere, aka, a "gopher seeking missile".
I am not sure how well a deployment bag will work when it is only attached to a relatively light object like your satellite. This is out of my area of expertise, unfortunately. You might choose to ask about this on the rocketry forum:
Wow, that photo of the "re-kitted" stuff looks pretty knarly, especially the 9V battery in upper center. I saw something like that when an 80 meter tower fell over and hit one of our anemometers on a rock on the ground. Or the system that became the object of an angry or simply curious black bear.
Chris, how fast do you want to collect data? There are probably ways to speed it up by running more of the operations in parallel. For example, there is a wait while the Sensirion completes the conversion of temperature and humidity. That waiting time could be interleaved with writing to the datalogger.
We were thinking one data sample every half second or so. This would equate to about one data point every 4-5 feet on the descent, which should be enough for our intents and purposes. There is a point where too many data points just wouldnt be neccesary. Ideally, once its programmmed we could change the read rate in order to fine tune the program to fit our needs. How much time would we save by running the operations in parallel. A few milliseconds may not be worth it, but if it is taking a good part of a second, it may be worth considering.
We made a run to a specialty battery store today, where we looked at different batteries they had, as well as what they could custom make to fit our needs. Meanwhile, we hooked the BOE to a repurposed r/c car battery (just over 7 volts) and let it run contiuously. When we plugged it in it had 7.48 volts, and four and a half hours later it still had 7.13 volts, which is encouraging. Were also working on wiring the MAWD and BOE power supplies together and to a battery connector, with power switch hard wired in between.
Good thinking about how often you need to acquire data in relation to the rate of descent. I ran the program with that in mind, but using the call to
GOSUB RTC_read
instead of to
GOSUB RTC_sync
That should make the program loop execute as fast as possible, given the time taken by each step in the loop. I found that still it takes a little more than a second for it to run around the loop each time. The slowest parts are the operations involved with opening, writing and closing the disk file, and also with waiting for the Sensirion to return data. Reading temperature takes longer than reading the humidity.
So, to get to 1/2 second is going to take some more work. I tried a couple of things, such as a more efficient purge routine for the vDrive, and an alteration of temperature and humidity readings, but so far only got it down to 4/5 of a second to run around the loop. We could gain quite a bit, I think, by buffering two records to the vDrive, so it would only have to be opened and closed for every other record.
Functionally, what is the difference between "read" and "sync"? What about that makes it execute as fast as possible?
I think we could take the same buffering concept and push it further. Couldn't we buffer, say, five records to the drive and only open it every fifth record? Even so, if the MAWDBOE were to stop working for whatever reason, we would only lose 20 or 25 feet of data (assuming one data point 4-5 feet) that hasn't been written to the drive. Considering the tens of thousands of feet of data to be recorded, that wouldn't be so much and may be worth the risk for the sake of efficiency.
Does anybody have an insights as to possible interference between a gps transmitter and the MAWD? This month's "Sport Rocketry" magazine features an article about one rocketeer who uses the exact same GPS transmitter/reciever set up we are using (a repurposed hunting dog tracking collar), and he mentioned that at times the transmitter interfered with his altimeter (MAWD) and made it think it was at altitudes it was not. What about a way to prevent such interference?
····· ·· 'Chute' is short for parachute. The pilot 'chute is a smaller parachute (sometimes called a drogue parachute) that pulls a larger parachute out. Wa the MAWD attached. tch some of the faster dragsters on TV and I think you'll see one.
Sylvie - How does the pilot 'chute attach to the main parachute...?
Static test update 1: We·ran the BOE datalogger on a 7.2 volt, 3300 mAh Ni-Mh battery without the MAWD attached
Started at 7:36 PM - 8.29 volts
Stopped at 6:57 AM -7.77 volts left
Total clock·time = 11 hours, 21 minutes
Actual time recorded on the·BOE was only 7:26:03 so datalogging stopped at 7 hours,26 minutes
553 kb of data was recorded; data flow and integrity looked good.
Static test update 2: We·ran the BOE datalogger on a 7.2 volt,·1500 mAh Ni-Cd battery without the MAWD attached
Started at·5:12 PM -·7.48 volts
Stopped at·9:35 PM·-7.13 volts left
Total clock·time =·4 hours, 23 minutes
Actual time recorded on the·BOE was only·4:21:53 so data flow was uniterrupted.
315·kb of data was recorded; data integrity looked good (no big gaps, corrupt data, etc.)
Question: Why would data flow stop during test #1, at 7 hours, 26 minutes, when there was more voltage left (7.7 volts) than there when test #2 started (7.48 volts)??
When I checked the datalogger first thing this morning, after it had run on battery power all night,·the light on the flash drive was blinking every second as though it was receiving data. But the BOE "red" light was not blinking (not sending data.)
Question #2: Should we shield the MAWD-BOE from the DC 20 locator/ transmitter (using something like an aluminum foil Faraday shield...?) Could the DC 20's transmitter's signal wreak havoc on the MAWD and the BOE? (*We'll try to ground test this at tomorrow's practice.) The transmitter is on the opposite side of the board from the MAWD-BOE.
As Christopher mentioned, there is an article in the month's NAR Sport Rocketry magazine about the exact Garmin transmitter we're using (Astro GPS - DC 20 combination.)
Our biggest qiestion is static test question #1: why did the data flow stop?
PS - Parallax has BOE Stamps on sale all weekend for on a mere $49. Tracy, should we spend the big bucks and update to another Stamp? Which do you suggest?
Mark in NH said... ····· ·· 'Chute' is short for parachute. The pilot 'chute is a smaller parachute (sometimes called a drogue parachute) that pulls a larger parachute out. Wa the MAWD attached. tch some of the faster dragsters on TV and I think you'll see one.
Sylvie - How does the pilot 'chute attach to the main parachute...?
Question #2: Should we shield the MAWD-BOE from the DC 20 locator/ transmitter (using something like an aluminum foil Faraday shield...?) Could the DC 20's transmitter's signal wreak havoc on the MAWD and the BOE? (*We'll try to ground test this at tomorrow's practice.) The transmitter is on the opposite side of the board from the MAWD-BOE.
As Christopher mentioned, there is an article in the month's NAR Sport Rocketry magazine about the exact Garmin transmitter we're using (Astro GPS - DC 20 combination.)
Our biggest qiestion is static test question #1: why did the data flow stop?
PS - Parallax has BOE Stamps on sale all weekend for on a mere $49. Tracy, should we spend the big bucks and update to another Stamp? Which do you suggest?
Thanks!
Mark
The pilot chute typically ties to an attachment point on the deployment bag, pulling the bag off of the main parachute (which is connected to the recovery harness at the other end). Here is a recent thread on deployment bags, though a bit more complex than I'm used to working with:
Re. shielding, that's out of my league, other than to say "be sure to ground test thoroughly". The interference reported in the Sport Rocketry article was from wiring that was a length that caused it to pick up RF signals.
Re. changing Stamp modules, you can get a faster one, as we discussed earlier. That would require you to change some of the numbers (everything that refers to timing, notably Baud rates for communicating with the MAWD, and possibly the datalogger - I haven't looked at your code to see how that's done).
==================
I flew the XBee/MAWD telemetry rocket again yesterday, on an I245G again, this time to 1641 feet. It worked beautifully. This time I had the LCD screen attached to the Stamp receiver board, so I could easily read off the altitude while in flight. The received data appeared on my screen with a little lag, as I could see when the rocket was nearing the ground. I was getting readings around 50 feet when it was at about 20 feet, and about 20 feet at the moment it landed. The delay was only about 1 second, not bad at all.
I also flew a boosted dart on an I357, which worked, though not dramatically so, and failed to deploy the main parachute, though with no damage. I also flew a standard dual deployment 3" PML Ariel on a Cesaroni I470 - beautiful straight flight to 3092 feet, perfect, close recovery. Today I fly the K805 in that radio-controlled deployment rocket.
Update: I flew the radio-controlled rocket to 3295 feet, the highest it has flown. The radio control worked perfectly and I had a great nearby landing. Unfortunately, the parachute draped over a tree, and it took some real effort to get it down. I also flew my 3" rocket on an I540, and the altimeter failed to fire either charge. Motor deployment saved most of the rocket - I came down under drogue - but the altimeter bay was destroyed. It happens, and I was overdue.
Post Edited (sylvie369) : 7/19/2009 9:36:26 PM GMT
·· It sounds like you had a great weekend of rocketry (except when the main parachute didn't deploy, and when the 'chute draped over the tree.) So your radio-controlled ejection worked on your highest flight ever? That's pretty cool! It must be·a thrill to watch your altitude on a monitor as the rocket descends. I'd like to see your apparatus (and maybe even build one this fall, after the ARLISS rocket is launched.)So what do you think happened when both ejection charges didn't fire on your 3" rocket? Did a battery came loose due to G-force? When will you launch next? Our club had a launch yesterday down in Massachusetts but I 'ran' a 5 mile race with my son. Despite (too) many rockets and motors, I haven't launched a rocket for almost two months... [noparse]:([/noparse]·· But I just bought a primo metal lathe and I plan to make Aerotech-style nozzles, and graphite inserts for nozzles... [noparse]:)[/noparse]
· The Rocketeers had an excellent practice today.·They pored over the deployment bag links you gave us·and figured out how all the parts connect to one another. Also, we connected a 7.2 volt Ni-MH battery to the MAWD, then to the BOE, and back to the battery (in series.) *It·was weird because the MAWD activated as usual but the BOE refused to initialize.* All we got from it was a feeble green LED for about 1 second. Then it faded. We reversed the wiring (battery to BOE to MAWD to battery) with the same results. We also hooked it up in parallel, with the same results. Yet the BOE runs A-OK on the same battery. When we tested the voltage coming out of the MAWD (into the BOE) it was 1.3 volts less than input voltage into the MAWD. So the MAWD "sucks up" voltage, maybe so much that the BOE can't initialize. So·right now·we can't run both the BOE and the MAWD from the same 7.2 battery. Any ideas on what's going on? Is the MAWD capacitor taking the voltage the BOE needs to turn on?
·· As I write this the BOE is running on the 7.2 volt Ni-MH battery while the MAWD outputs to it from a 9-voly Lithium battery. We're testing to see how long each will last, and if we dare to use a stand-alone lithium battery for the MAWD. Mollie and Christopher calculated that with a 38 minute descent time; time in the rocket; and time on the ground, the MAWD and the BOE need a minimum of 5 hours of battery time. I think that's close to reality.
Tracy,
·· We talked over the read rate at practice again today and the kids decided to leave well enough alone. The current program works great and it should generate ample, and accurate data·for their project report.·Taking additional time to speed·up the read rate would slow things down and the overall gain would be marginal, especially since they have to finish building the ASP (the payload platform the MAWD-BOE mounts on.) What are your thoughts on this? It's hard to believe, but we only have TWO more "build time" practices, in mid-August. Our single practice in September will be packing to leave for Nevada! What did you do this weekend? Do you do any hiking?
I think that you should power the MAWD from a 9V battery, and the BOE from the 7.2V RC battery. Remember that you will still need a common ground so that BOE will have a reference for the·serial data from the MAWD. A 9V Duracell is rated at 550 mAH, and the MAWD instruction manual says "operating current: 8 Ma typical", so you would hope to get 550/8 = 68.75 hrs of life. Obviously that's very rough, but it has plenty of leeway if you just need 5 hrs, especially as you're not drawing current from the firing terminals (though I suppose it might still use current on those outputs even with no e-matches attached - I'm pretty sure it can't, though, as it's an open circuit there).
I also think that if you're measuring altitude and a couple of gas concentrations, one or two readings per second should be just fine, especially, again, since you're not interested in the data on the way up (the part of the flight at which things change very quickly). If it were me, I'd put my effort now into making the system bullet-proof rather than into trying to increase the sample rate.
I don't know what went wrong with that flight of mine that crashed. In a few days I'll test the altimeter, and see if it's still good. It's a Perfectflite HA45, the only one of those that I have. The battery seemed to be still in place, and I did check the arming switch, and it was armed (I though I might have forgotten to arm it - that happens pretty often, though I haven't done it yet). The battery is still putting out more than 9V, even though it's not really rectangular anymore The leads were still connected firmly.
Hi Mark,
I've been away over the weekend at Pt. Reyes Nat. Park and blissfully away from keyboards and screens!
I don't think you should spend "big bucks" to update to another Stamp. Stick with what you have. There isn't much time left! On the other hand, a backup BOE is always a a good idea.
You said the Rocketeers connected the BOE and the MAWD in series to the battery, and I gulped, "oh no!". That won't work, but you already know that. But then, "We also hooked it up in parallel, with the same results.", which I find hard to understand. I think there must have been something miswired there too. It should be possible to supply power in parallel to the BOE and the MAWD, as per the attached diagram. Or, you can use a separate battery for the BOE and the MAWD, as Sylvie points out, and be sure to note the statement about the common ground.
If the program is working fine and already records data fast enough, I agree about leaving well enough alone. Better to focus on the "bullet proof" part. The anomaly in your first "static test" is troubling, why did it stop taking data after a duration of 7:26 instead of at the total clock time of 11:21? That could be one of those things that go bump in the night, something that you don't want to happen during a flight.
Let me try this again.The internet just ate a long reply without posting it...!
We're away·on college visits for several days but we did get the MAWD-BOE Air Sampling Probe assembled before we left. We also did·more battery testing, with encouraging results. The BOE ran for 15-1/2 hours connected to the Ni-MH rechargeable battery and it only used 1.2 volts. It gave error-free data and might well have run for another 15 hours. The MAWD ran for 5-1/2 hours on a 9-volt lithium battery and it used less than·one volt. It also gave complete, flawless data. The two weren't connected and they will run on independent power supplies in flight.
The batteries are very securely mounted (bolted) on to one side of the ASP platform and the MAWD-BOE is bolted to the other side (see attached photos.) All connections are soldered and the 9 volt battery is secured with a piece of rubber surgical tubing (the yellow thingy in the photo.) One of the next things we have to do is shorten the plaform so we have more room for parachute(s). We calculate we'll have 2-3/4" to 3" of height·and 5-3/4" diameter. The team is doing more research on parachute bags, parachutes, and descent rates. Although it feels heavy, the MAWD-BOE weighs just shy of 1 kg (2.2 pounds) and we may be able to use a much smaller parachute than we thought.·Ideally we'd like·a descent rate of 10 fps, or less.
Sylvie,
Thanks for the cool launch photo (you at the computer)! So that's the gizmo, huh? It looks fairly straightforward (and you look like a happy camper.) Did you launch over the weekend? When's you're next launch, on what new gadgetry? Doubtful I'll have the chance to launch for at least a few weeks· =(
Christopher interviewed at Swarthmore College today. It's a nice campus with an excellent liberal arts program. From here we'll visit U Penn, Johns-Hopkins, George Washington, Georgetown, American University, Haverford, and Columbia. Then back home where we visit Bowdoin (12 miles from our summer home), Dartmouth, and Tufts (again.) Christopher wants to study international affairs and I think he's on the right track. His interviews have gone·really well so far. Any advice on the college interview process, Tracy or Paul? Any advice on the MAWD-BOE...?
Sounds/looks good with the batteries.·A couple of comments:
First, is there something holding the 9V battery down? It's hard to tell from the photos - it looks like there might be something across the ends. If not, a zip tie through the board and across the battery will do the trick. OH WAIT - I get it. The rubber tubing folds down over it, and is secured with the screw. Okay. Never mind.
Second, you wrote "The MAWD ran for 5-1/2 hours on a 9-volt lithium battery and it used less than·one volt". That's great, but suggests that you might have a misconception. The volts aren't a measure of the capacity of the battery, at least in the "battery life" sense. For example, if you used 1 volt in 5 hours, that wouldn't mean that you had 9 x 5 = 45 hours of battery life. Take a look here and you'll see how these things are measured:
You'll see that the voltage of these batteries drop a little over their useful life, and then suddenly drop like a rock from about 6V to 0V when they're out of juice, as it were.
Saying that a battery has 9V is more like saying that a car will·hold 4 adults than it is like saying that it'll go 300 miles before it's out of gas.
Now, you're apparently getting plenty of life out of your battery, so I wouldn't worry. It's worth noticing (on the page with the tests) that there is significant variation in the lifetimes of different 9V batteries, so don't go changing brands/types from your tests to your actual launch. Launch what you tested.
Third, I see a toggle switch on the board. I assume that the entire thing will be enclosed in a tube of some sort, correct? If not (which would surprise me very much) the toggle switch will be a problem. Those things love to snag shock cords, which flips them to "off". Iron clad rule: toggle switches are not to be mounted on the exterior of a rocket.
Fourth, I understand "Rocket Rage" makes parachutes that pack to a very small size:
I've always wanted one. It looks like they're all too large though for your purposes. Top Flight (Gary Pletzer, a local guy who I see regularly) makes some really wonderful "thin mill" parachutes that pack quite small. It looks like they come in sizes up to 30" and down to 9":
Fifth - yup, that's me with the gizmo. I'm still trying to gather photos so that Sport Rocketry will have something to publish. I'm sending them a package with the article (revised to cover the second launch) and a CD of photos. Unfortunately, the photo is a little blurry - it's hard to find people who can use a digital camera correctly, even at a high-tech rocket launch.
Sixth: re. college advice - writing clearly REALLY matters. Contrary to popular opinion, we college folks are not at ALL impressed by big words (I rant at students who say "utilize" when they could have just said "use"). We want nice short clear sentences, each of which expresses an idea. Eagerness to learn also matters a lot, and these rocket projects clearly demonstrate that your students have that eagerness.·A demonstrated ability to work in a team on a project that has iron-clad deadlines is also a big plus, and your students have demonstrated that as well.
My dad graduated from Tufts many many years ago, with a degree in physics. In WWII he worked in the China-Burma-India theater on radio beacon guidance systems for our B-29s. Then he came home and went into building automation (to increase efficiency of heating and AC systems in buildings) with Johnson Controls: we were doing "green technology" in my household all the way back in the 1960s, and "going green" put me through college and left my mom with a comfortable pension after my dad's death.
Anyway, International Affairs sounds like a great choice. I wish I'd done something with an international side to it when I was in college, though that seemed like a complete pipe dream to me at the time.·I never really got to travel until I was in my 30s and 40s, though I've made up for lost time pretty well. International travel changes you in a very good way, and if you can change at a younger age, it's that much more valuable.
Finally, I didn't fly rockets this past weekend, but we do have another launch in two weeks. This weekend I went to some minor league baseball games, and watched the air show here on the Milwaukee lakefront: F-15s, an F-18, the Thunderbirds in F-16s, several aerobatics teams, and the Army Golden Knights parachute team. I have the luxury of being able to watch from a nice hill at the end of my block.
This week is the beginning of the Experimental Aircraft Association annual convention, which means that the busiest airport in the world is in Oshkosh, Wisconsin (there's a nice trivia question for your friends). The Airbus A380 - world's largest passenger jet - landed here at the Milwaukee airport today on its way up to Oshkosh. There's lots of interesting stuff in the air around here these days.
Update: I flew the MAWD/XBee again yesterday, for its third test flight. This time it was in a rocket with a dual deployment setup, so I was able to fly it a little higher to test both the range and whether or not it interferes with the MAWD's ability to fire ejection charges. I flew it in a 4" rocket on an I366 Redline, to 2002 feet, and had no trouble staying in contact with the rocket throughout the flight. Due to winds, it went quite a bit further downrange than in the other test flights, landing at least 1/2 mile away (in some very sharp bushes - my legs are bloodied). I had data all the way down to the ground. I'd estimate it was about 3500 feet away at the furthest point (that's a WAG, of course). The RF didn't cause any trouble at all for the MAWD's deployment function, and the main parachute charge - set for 500 feet - went off within a second·or so of when the ground receiver said we were at 500 feet. In short, everything worked as I'd hoped.
I'd also wanted to fly it to about 3000 feet on a J500, but the weather and time didn't cooperate. I'd also hoped for a chance to get out today and try it, but it's raining. Maybe in two weeks, at our big public launch.
I flew the XBee/MAWD again yesterday, twice. First it went up on another I245G, to only 1049 feet in fairly high winds, with good data throughout yet again. Then I got gutsy, and put it up on the J500G. It flew to 2679 feet, and amazingly (to me, anyway), still stayed in contact throughout the flight. The datasheet says it should get a range of 1 mile, but I'm probably getting pretty close to that without any issues, and I generally expect that datasheets give the absolute "best case" estimates. In this case, 1 mile is starting to look completely realistic, given I was almost 2700 feet up and quite a ways downrange.
Unfortunately, my main parachute failed to deploy, and I hit the ground at somewhere over 80 MPH. There's a nice dent in the big capacitor on the MAWD, and I wouldn't trust it to fire ematches anymore (though it was dutifully beeping out the altitude when I got to the landing site). The XBee and board are just fine. The rocket's fin can is now trash, though. I'll have it up and flying on a different fin can by the next launch, in two weeks.
The datasheet says it should get a range of 1 mile
I assume that's·the XBee data sheet? This is a real-time data downlink, yes?
I'm probably getting pretty close to that without any issues, and I generally expect that datasheets give the absolute "best case" estimates. In this case, 1 mile is starting to look completely realistic, given I was almost 2700 feet up and quite a ways downrange.
Bummer that your main 'chute failed to deploy, especially on an expensive rocket with lots of time in it. *I never tell my wife how much the rocket really costs, especially after a crash or a CATO. It's pretty amazing that the MAWD was still beeping out data and that the XBee was intact! I suppos if all you lost was a fin can, you should consider yourself lucky! Excellent altitude graph, by the way.
We figured out the 'pilot parachute deployment bag'. It was really simple to make, and very small. Basically it's a small nylon bag, about the size of a sandwich bag, with a small clip inside to clip to the top-center of the main 'chute. The outside has a small Kevlar loop sewn on, and that's where the 24" pilot chute attaches. We've ground tested it and it seems to work perfectly ("seems" being the operative word.) The launch and receovery will tell all. I really need to get updated pictures posted so you can see.
The team shirts and mission patches have arrived and they look awesome! If you give me an address and a·shirt size·(you too, Tracy) we'll get yours out to you in the mail. Or, if you come to the ARLISS launch... we'll present it to you at the breakfast banquet. Hopefully we'll have lots (of data) to celebrate, and an intact MAWD-BOE-ASP. It's finished, it works very well, and it looks very professional. I'll check in later and post more often.
Yup, the XBee datasheet says 1 mile of range, and I'm starting to believe them. Those XBees are amazing. You should think about sending your data down by radio link next year instead of onboard logging.
Last night I hooked the MAWD up to the data download software. The data downloaded just fine, and all of the tests worked. I didn't burn ematches on the output test, but it did light the two LEDs I usually use to test outputs. I think that MAWD might still be in working condition despite the dented cap. But better yet, I got the idea of using it ONLY to send the altitude data, and using another altimeter for deployment. I've been looking for a place to use that new Missileworks RRC2, and that's the place.
As for the "great looking altitude graph", I prefer it when the graph levels out a bit at 500 feet.
Congrats on the pilot chute thing. The main chute pulls out smoothly when you pull JUST on the pilot chute, right? That's what matters.
I seriously looked into coming to the ARLISS launch, but unfortunately it's in the middle of a very busy time for me. I'd have loved to have come. I'll PM you a mailing address - thanks!
···· So the MAWD gave you data despite the dented capacitor? That's excellent that it still works. I guess I'd be cautious about using it for primary deployment though, especially on a a primo rocket.
So you can connect LED's to the main and drogue outputs instead of e-matches, to check whether the outputs·work? That's a clever idea. What happens when you draw a vacuum on the MAWD? Do the LED's flicker for a moment at "apogee" and at (a theoretical) "500 foot" altitude? How long do the·LED's stay on? That's a great way to save e-matches!
During TARC we discovered that Quest·sells low-amp igniters that can be ordered by mail. They're inexpensive and they work as well as a regular e-match. I'm not sure how they·might work on larger projects, but there is enough pyrogen on the tip·to ignite virtually any amount of Pyrodex, etc. We simply solder wires on to the igniter wires·to make them·any length we need.
I tried to upload some jpeg's of the finished MAWD-BOE-ASP from (my cheesy, slow dial-up) home computer but it was tooslow and the jpeg's were too large. So I'll take them in to school and post them from there.
ARLISS is sending us·a "Big Red Bee" GPS transmitter to·mount on the ASP so they can transmit real-time data through their Virtual Classroom downlink. It's a long distance (high power?) shortwave transmitter. Question: Do we need to shield the shortwave transmitter from the ASP to prevent possible data corruption?· Is it likely the short waves (electromagnetic waves) could 'zap' the ASP and it's data? The two units will be only a few inches apart.
PM e-mail is mkibler@unity.edu·- It'd be cool if you could make it ARLISS....!
I'm not as worried about a "primo rocket" as I am about people and things on the ground below. I fly at Bong Recreation Area, which isn't exactly Black Rock as far as remoteness goes. There are non-rocketry people in the park, and of course all of our cars.
I didn't come up with the LED idea myself - I got it from Xavien, which sells a little kit for testing these kinds of devices. The LEDs need resistors, of course: I'm not sure what size they're using, but they work. The LEDs come on as long as the MAWD output is latched on, which is about 1 second.
I'm not drawing a vacuum in a vacuum bottle yet for testing: the MAWD software has a couple of buttons to test the outputs without having to simulate flight, and that's what I used yesterday.
The question about the Big Red Bee GPS unit is probably best answered by one of the experts here. For their information, here's the relevant BRB webpage:
It's not technically a "shortwave" device, but rather a 70cm (433 MHz) device, just like their regular transmitter. It requires an Amateur Radio license to operate: I assume the ARLISS people have a Ham among them who can legally use this device? I got my Amateur Radio license explicitly for the purpose of legally using a Big Red Bee transmitter.
Edit: Oh, re. those Quest Q2G2 igniters - yup, they're great. Be careful with them though - some of the continuity checkers on launch systems will set them off. They fire with very low current. If you're using them to light a motor, either get clear before doing the continuity check or test them with your system before putting them into a motor. You do not want to be next to the pad doing a continuity check and have your motor light.
Post Edited (sylvie369) : 9/2/2009 11:15:41 AM GMT
Comments
·
Thank you all for time and help,
·
Sean from ARLISS-NH
Sean - A parachute bag (or more often "deployment bag") is a flameproof bag that the main parachute goes into. It protects the parachute from the ejection charge, and also helps ensure "orderly deployment". A small pilot chute pulls the deployment bag out of the rocket. It pulls the shock cord straight, and then pulls the shroud lines out of the bag. Finally the main chute is pulled out and inflates. Pulling the shock cord and then shroud lines straight before inflating the main chute significantly reduces the stress on the system. It also reduces the chance of things tangling.
I don't usually fly with a deployment bag, but I've been looking into using one more. I have one for my 4" rocket, and flew it a couple of times.
Paul
·· The "satellite" is the MAWDBOE/ ASP payload (since the proejct is called the Rocket Launch for International Student Satellites, or ARLISS.)
When the MAWD-BOE deploys, the payload bay and the nose cone will be pointed straight down. The MAWD-BOE is ejected 4-6 seconds after apogee withe nose cone pointing downward. One of the ARLISS guys suggested putting·our parachute under the MAWD-BOE in a parachute bag so the MAWD-BOE pushes the parachute/ bag·out ahead of it. We wonder whether the MAWD-BOE will have so·much ejection force that it basically embeds itself in the parachute (with ·the whole mess just tumbling to the ground, tangled.)
In the past, our payloads have·come out ahead of (above, or behind) the parachute so the parachute·opens·above the payload. If we do it this way, the fellow at ARLISS thinks there will be so much stress force that the parachute will simply tear itself off of the MAWD-BOE/ ASP payload. I think there will be more stress force doing it the other way because the paylaod will have more time to accelerate toward the ground before the parachute comes out of the parachute bag (f·= m x a.) We plan to use a rubber surgical tubing shockline attached Kevlar, attachd, to the parachute... What are your thoughts? Does this make sense?
It's midnight, and the MAWD-BOE is now officially mounted·to the ASP payload module! (I'll send pictures.) Tomorrow we'll permanently wire the MAWD to the BOE the re-test it in the vacuum chamber.·Then we have to start searching for long-lasting power supplies (not just·a 9-volt lithium battery.) We also have to connect the Kevlar shockline and surgical tubing, and ground test the parachute. We've kicked around the idea of using the MAWD's second ejection charge to activate a colored smoke flare at 1,000' AGL, bu that's down the road, only if we have 'extra' time (I can visualize the whole thing catching fire-- in color--·1,000 before it lands!)· But we're moving along (yawn!)
I'm eager to hear more about all the electronics you're testing and launching in your rockets. and where do you have the luxury of launching J and K motors so often (lucky guy!) Thanks for the code you posted for Christopher.He mused over it and did a lot of reading, then started programming. I'm not sure what the outcome was (but I didn't hear "Eureka"!)
**Can I simple cut the other un-used wires off the MAWD's data download cable since only the brown and blue wires are used? I plan to connect them (the blue and brown wires) directly to the BOE'sPIN 15 and Vss.)
Don't stay up too late,
Mark
·· Let me clarify. I said: In the past, our payloads have·come out ahead of (above, or behind) the parachute so the parachute·opens·above the payload.
What I meant to say was that, in the past, our·payload comes out first and the parachute second (opening above the payload.) The ARLISS guy suggests the opposite: The parachute comes out first, followed by the MAWD-BOE "satellite" (*on top of the parachute.) Will it open...?
Mark
Hi Tom,
The Stamp works strictly with integers and does integer math. When it divides 1 by 2, its answer is zero. It takes the whole number result and drops the remainder.
The interval is held in the constant,
When you enter a 1/2 there instead of 1, the Stamp happily uses its integer math and calculates, logInterval = zero.
When you enter 0.5 there, it will, I think, scream, "syntax error!", because the Stamp does not know what to do with the decimal point.
As it stands, in the MAIN loop, there is a call to a subroutine called "RTC_sync".
What that subroutine does is, it reads the DS1302 clock chip repeatedly, very fast, and it looks for a change in the seconds. That is a change from 1 to 2, or from 2 to 3 and so on up to 59 back to zero. It can't detect anything less than a one second change, because the DS1302 ticks off seconds, no finer than that. If you want to have faster cycling, one way to do it is to replace the above statement in the main loop with this one:
That way if you enter zero as the log interval:
the logger will take data as fast as possible, and not try to sync to the tick of the seconds. It will still of course read the DS1302 clock and store the time in your USB log file.
You told me that when you entered 1/2 for the logging interval, the logger just sat there and did nothing. You know now that the Stamp integer math turns that into a zero. But that doesn't explain why it just sat there. (Anyone not interested in why can stop reading.) Here is the RTC_sync subroutine:
rtc_Sync: ' paces data logging to the number of seconds specified in CONstant "logInterval" buffer=logInterval*200 ' this variable is used as a temporary counter DO:DO GOSUB RTC_read buffer=buffer-1 ' this countdown is an escape from loop in case RTC fails LOOP UNTIL second<>second0 OR buffer=0 ' second0=second ' change, update old value for tracking LOOP UNTIL second.NIB1*10+second.NIB0//logInterval=0 OR buffer=0 ' wait for log interval to arrive ' DEBUG CR,?buffer RETURNThe variable buffer is used here as a simple 16 bit integer (ignore any connotations of the word "buffer"). At the top that is set equal to logInterval*200, so when logInterval=0, the buffer=0. The purpose of that variable is to act as an escape hatch in case the RTC stops working for any reason.
Why would the RTC stop working?
The variable "buffer" counts the number of trys and it can time out if the clock stops, and escape from the subroutine so data logging can continue at intervals. Anyway, if logInterval=0 and buffer=0, then it has to count all the way around from 65535 back to zero, because of the way the loop is set up to subtract buffer-1 for each try. That takes a very very long time, by my calculation, about 350 seconds.
That is why I suggested making zero a special case for logInterval, to mean "as fast as possible". But you can still revert to intervals that sync to the seconds. If you always want to log data as fast as possible, then change the statement in the main loop to
Then there is no call to the RTC_sync subroutine and you can delete it and also the logInterval CONstant. By the way, the RTC_read routine will not lock up, even if the clock chip breaks. Both the SHIFTIN and I2CIN commands on the Stamp have a built-in timeouts. If the clock breaks, logging will continue with sample after sample, just without a good timestamp.
edit: meant to say that the SHIFTIN command for the DS1302 has a builtin timeout. The I2CIN command (That I use for the DS1307 RTC on my own loggers) also has a built-in timeout.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 7/15/2009 3:50:04 PM GMT
If your concern is about the payload tangling the shroud lines, that's one of the things that·a deployment bag is meant to avoid. The shroud lines are inside the bag as the bag/chute and the payload go past each other. I guess the lines on the pilot chute could tangle with the payload, but the shroud lines on the pilot chute are quite short, so that's not very likely.
I'm still not quite following what is connected to what. The rocket arcs over. A few seconds after apogee, the apogee charge fires, pushing off the nose cone. I assume that there's a drogue chute of some sort on the rocket itself.
Does your payload (the "satellite") come down entirely separately from the rocket itself?
If so, are you opening a main chute at more than 10,000 feet in the air?
If so, how do you plan to recover the payload?
Or is the satellite still attached to the rocket somehow?
If the satellite does eject completely and come down separately from the rocket, I don't think that it makes that much difference whether the parachute is above or below the satellite while it sits inside the rocket. I assume they're helping you to pack the parachute? The shroud lines should be folded inside of the parachute, so that they're not exposed until the chute is opening, and so that they don't wrap around the chute and prevent it from opening. When it is all ejected, it'll probably flop around so much in the first second or two that by the time the chute opens, it makes no difference whether it was above or below the satellite while inside the rocket.
Will your satellite be the only one inside the rocket? If not, I'd be more concerned about fouling with other things being ejected than I would about the order of parts on my own satellite.
All of that being said, I definitely defer to the ARLISS people, or at least to whichever local expert actually has the whole setup sitting in front of him.
Re. the idea of using a flare, be very careful. I've seen it done, but it has a very high potential for starting a fire. This is a particularly sensitive topic here today:
http://www.jsonline.com/news/crime/50790692.html
A flare that some idiot fired up on top of the Patrick Cudahy factory last week·started a major fire that lasted three days, required the attention of several fire departments, required the evacuation of every home in a mile radius, and put quite a few people temporarily out of work. I know there won't be that much chance of anything like that where you're flying, but flares should be treated as dangerous. We don't ever use flares or smoke cannisters on our rockets, because we fly in a prairie (Bong Recreation Area) where (as Pavel found out) there is a very real risk of wild fire. We generally use radio beacons for finding our rockets if they fly very high, or sonic beacons (personal alarms) if they're not going that high. I'll have a Big Red Bee 433 MHz beacon in my boosted dart this weekend.
Re. my having lots of opportunities to fly, I live in a very active area (south eastern Wisconsin), with both NAR and Tripoli clubs. During the summer there are typically two high power launches a month right at Bong, plus others at other fields within a day's drive.
Does your payload (the "satellite") come down entirely separately from the rocket itself?
> YES· (and the nose cone descends on a separate parachute. The payload and booster are on a third 'chute.)
If so, are you opening a main chute at more than 10,000 feet in the air?·····················
> YES. And a big one, too!......... drift --> ?·........................................................................drift --> ??
If so, how do you plan to recover the payload?·······················································
> We're using a Garmin Astro DC 20 dog tracker/ transmitter mounted on the payload. It transmits to a GPS and
································································································································ it has a 5+ mile range. We had access to it so we used it. I would prefer a BigRedBee transmitter, but... $$$
Or is the satellite still attached to the rocket somehow?···········································
> NO
Will your satellite be the only one inside the rocket?·················································
> YES
··· So·when you·use a parachute bag, does it always·use a pilot (drogue?) parachute to pull out the main parachute? This is·a first for me.
··· If we do use a flare, etc: 1) Black Rock is a dry lake bed (so they say); and 2) We'll be sure to consult Pavel!
Christopher was intrigued by the programming suggestions you posted last night and he mused over them for hours. He tried using VAR· 0.0110010 (with a decimal point) and didn't get beyond that point. Now he's·poring over Tracy's latest lesson...! Thanks Tracy [noparse]:)[/noparse]
More later,
Mark
I understand about the satellite now. I think the Garmin GPS will be the best way you could go for recovery. I guess things are different at Black Rock - here we'd be worrying about being in a tree or a pond or some other inaccessible place.
I do believe that deployment bags always use pilot chutes, but I could be wrong about that. Here is the bag I have, and a link to some instructions for using them:
http://www.quickburst.net/ndb_4.htm
Thanks for the help.
· Thanks for the link to the Quickburst website. I understand the deployment bag idea a bit better now. So the pilot 'chute stays outside of the deployment bag, right? It rests atop the bag and pulls the main 'chute out?
We don't have lots of space·inside the payload bay,·on top of the "satellite", for a large parachute/ apparatus. It will have to be compact.·We have 5.75" diameter to work·with, but only about 4" in height for the parachute.·That's determined by the maximum allowable length (9.75") minus the height of the "satellite" (5.75".)·I'll have to·uplink some·photos now that the MAWD-BOE is mounted on the payload platform (the ASP.)
Visualize two, 5.75" diameter x 1/2" thick bulkheads connected with a 9" piece of 1/2" thick wood. That's the platform the MAWD-BOE is mounted on. The parachute attaches to the upper bulkhead. The nose cone has a bulkhead of its own, which sits atop the parachute.
Attached is a photo that explains why we want the parachute to work well... and what we don't want...~! One of the ARLISS guys sent it to Sean to let us know what could happen if things get ugly at deployment time.
Mark
It looks like the result of a rocket that transitioned to a high density layer of the terrasphere, aka, a "gopher seeking missile".
I am not sure how well a deployment bag will work when it is only attached to a relatively light object like your satellite. This is out of my area of expertise, unfortunately. You might choose to ask about this on the rocketry forum:
http://rocketryforum.com/index.php
If the d-bag is okay with just a satellite, you might well find that it takes less room than a parachute without a bag.
Chris, how fast do you want to collect data? There are probably ways to speed it up by running more of the operations in parallel. For example, there is a wait while the Sensirion completes the conversion of temperature and humidity. That waiting time could be interleaved with writing to the datalogger.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
We were thinking one data sample every half second or so. This would equate to about one data point every 4-5 feet on the descent, which should be enough for our intents and purposes. There is a point where too many data points just wouldnt be neccesary. Ideally, once its programmmed we could change the read rate in order to fine tune the program to fit our needs. How much time would we save by running the operations in parallel. A few milliseconds may not be worth it, but if it is taking a good part of a second, it may be worth considering.
We made a run to a specialty battery store today, where we looked at different batteries they had, as well as what they could custom make to fit our needs. Meanwhile, we hooked the BOE to a repurposed r/c car battery (just over 7 volts) and let it run contiuously. When we plugged it in it had 7.48 volts, and four and a half hours later it still had 7.13 volts, which is encouraging. Were also working on wiring the MAWD and BOE power supplies together and to a battery connector, with power switch hard wired in between.
Good thinking about how often you need to acquire data in relation to the rate of descent. I ran the program with that in mind, but using the call to
GOSUB RTC_read
instead of to
GOSUB RTC_sync
That should make the program loop execute as fast as possible, given the time taken by each step in the loop. I found that still it takes a little more than a second for it to run around the loop each time. The slowest parts are the operations involved with opening, writing and closing the disk file, and also with waiting for the Sensirion to return data. Reading temperature takes longer than reading the humidity.
So, to get to 1/2 second is going to take some more work. I tried a couple of things, such as a more efficient purge routine for the vDrive, and an alteration of temperature and humidity readings, but so far only got it down to 4/5 of a second to run around the loop. We could gain quite a bit, I think, by buffering two records to the vDrive, so it would only have to be opened and closed for every other record.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I think we could take the same buffering concept and push it further. Couldn't we buffer, say, five records to the drive and only open it every fifth record? Even so, if the MAWDBOE were to stop working for whatever reason, we would only lose 20 or 25 feet of data (assuming one data point 4-5 feet) that hasn't been written to the drive. Considering the tens of thousands of feet of data to be recorded, that wouldn't be so much and may be worth the risk for the sake of efficiency.
Does anybody have an insights as to possible interference between a gps transmitter and the MAWD? This month's "Sport Rocketry" magazine features an article about one rocketeer who uses the exact same GPS transmitter/reciever set up we are using (a repurposed hunting dog tracking collar), and he mentioned that at times the transmitter interfered with his altimeter (MAWD) and made it think it was at altitudes it was not. What about a way to prevent such interference?
What does the pilot chute do? Chute refers to parachute right?
Thank you all for your time and help,
Sean from ARLISS-NH
·· 'Chute' is short for parachute. The pilot 'chute is a smaller parachute (sometimes called a drogue parachute) that pulls a larger parachute out. Wa the MAWD attached. tch some of the faster dragsters on TV and I think you'll see one.
Sylvie - How does the pilot 'chute attach to the main parachute...?
Static test update 1: We·ran the BOE datalogger on a 7.2 volt, 3300 mAh Ni-Mh battery without the MAWD attached
Started at 7:36 PM - 8.29 volts
Stopped at 6:57 AM -7.77 volts left
Total clock·time = 11 hours, 21 minutes
Actual time recorded on the·BOE was only 7:26:03 so datalogging stopped at 7 hours,26 minutes
553 kb of data was recorded; data flow and integrity looked good.
Static test update 2: We·ran the BOE datalogger on a 7.2 volt,·1500 mAh Ni-Cd battery without the MAWD attached
Started at·5:12 PM -·7.48 volts
Stopped at·9:35 PM·-7.13 volts left
Total clock·time =·4 hours, 23 minutes
Actual time recorded on the·BOE was only·4:21:53 so data flow was uniterrupted.
315·kb of data was recorded; data integrity looked good (no big gaps, corrupt data, etc.)
Question: Why would data flow stop during test #1, at 7 hours, 26 minutes, when there was more voltage left (7.7 volts) than there when test #2 started (7.48 volts)??
When I checked the datalogger first thing this morning, after it had run on battery power all night,·the light on the flash drive was blinking every second as though it was receiving data. But the BOE "red" light was not blinking (not sending data.)
Question #2: Should we shield the MAWD-BOE from the DC 20 locator/ transmitter (using something like an aluminum foil Faraday shield...?) Could the DC 20's transmitter's signal wreak havoc on the MAWD and the BOE? (*We'll try to ground test this at tomorrow's practice.) The transmitter is on the opposite side of the board from the MAWD-BOE.
As Christopher mentioned, there is an article in the month's NAR Sport Rocketry magazine about the exact Garmin transmitter we're using (Astro GPS - DC 20 combination.)
Our biggest qiestion is static test question #1: why did the data flow stop?
PS - Parallax has BOE Stamps on sale all weekend for on a mere $49. Tracy, should we spend the big bucks and update to another Stamp? Which do you suggest?
Thanks!
Mark
http://rocketryforum.com/showthread.php?t=4710
Re. shielding, that's out of my league, other than to say "be sure to ground test thoroughly". The interference reported in the Sport Rocketry article was from wiring that was a length that caused it to pick up RF signals.
Re. changing Stamp modules, you can get a faster one, as we discussed earlier. That would require you to change some of the numbers (everything that refers to timing, notably Baud rates for communicating with the MAWD, and possibly the datalogger - I haven't looked at your code to see how that's done).
==================
I flew the XBee/MAWD telemetry rocket again yesterday, on an I245G again, this time to 1641 feet. It worked beautifully. This time I had the LCD screen attached to the Stamp receiver board, so I could easily read off the altitude while in flight. The received data appeared on my screen with a little lag, as I could see when the rocket was nearing the ground. I was getting readings around 50 feet when it was at about 20 feet, and about 20 feet at the moment it landed. The delay was only about 1 second, not bad at all.
I also flew a boosted dart on an I357, which worked, though not dramatically so, and failed to deploy the main parachute, though with no damage. I also flew a standard dual deployment 3" PML Ariel on a Cesaroni I470 - beautiful straight flight to 3092 feet, perfect, close recovery. Today I fly the K805 in that radio-controlled deployment rocket.
Update: I flew the radio-controlled rocket to 3295 feet, the highest it has flown. The radio control worked perfectly and I had a great nearby landing. Unfortunately, the parachute draped over a tree, and it took some real effort to get it down. I also flew my 3" rocket on an I540, and the altimeter failed to fire either charge. Motor deployment saved most of the rocket - I came down under drogue - but the altimeter bay was destroyed. It happens, and I was overdue.
Post Edited (sylvie369) : 7/19/2009 9:36:26 PM GMT
·· It sounds like you had a great weekend of rocketry (except when the main parachute didn't deploy, and when the 'chute draped over the tree.) So your radio-controlled ejection worked on your highest flight ever? That's pretty cool! It must be·a thrill to watch your altitude on a monitor as the rocket descends. I'd like to see your apparatus (and maybe even build one this fall, after the ARLISS rocket is launched.)So what do you think happened when both ejection charges didn't fire on your 3" rocket? Did a battery came loose due to G-force? When will you launch next? Our club had a launch yesterday down in Massachusetts but I 'ran' a 5 mile race with my son. Despite (too) many rockets and motors, I haven't launched a rocket for almost two months... [noparse]:([/noparse]·· But I just bought a primo metal lathe and I plan to make Aerotech-style nozzles, and graphite inserts for nozzles... [noparse]:)[/noparse]
· The Rocketeers had an excellent practice today.·They pored over the deployment bag links you gave us·and figured out how all the parts connect to one another. Also, we connected a 7.2 volt Ni-MH battery to the MAWD, then to the BOE, and back to the battery (in series.) *It·was weird because the MAWD activated as usual but the BOE refused to initialize.* All we got from it was a feeble green LED for about 1 second. Then it faded. We reversed the wiring (battery to BOE to MAWD to battery) with the same results. We also hooked it up in parallel, with the same results. Yet the BOE runs A-OK on the same battery. When we tested the voltage coming out of the MAWD (into the BOE) it was 1.3 volts less than input voltage into the MAWD. So the MAWD "sucks up" voltage, maybe so much that the BOE can't initialize. So·right now·we can't run both the BOE and the MAWD from the same 7.2 battery. Any ideas on what's going on? Is the MAWD capacitor taking the voltage the BOE needs to turn on?
·· As I write this the BOE is running on the 7.2 volt Ni-MH battery while the MAWD outputs to it from a 9-voly Lithium battery. We're testing to see how long each will last, and if we dare to use a stand-alone lithium battery for the MAWD. Mollie and Christopher calculated that with a 38 minute descent time; time in the rocket; and time on the ground, the MAWD and the BOE need a minimum of 5 hours of battery time. I think that's close to reality.
Tracy,
·· We talked over the read rate at practice again today and the kids decided to leave well enough alone. The current program works great and it should generate ample, and accurate data·for their project report.·Taking additional time to speed·up the read rate would slow things down and the overall gain would be marginal, especially since they have to finish building the ASP (the payload platform the MAWD-BOE mounts on.) What are your thoughts on this? It's hard to believe, but we only have TWO more "build time" practices, in mid-August. Our single practice in September will be packing to leave for Nevada! What did you do this weekend? Do you do any hiking?
Regards from (finally sunny) New Hampshire,
Mark
I think that you should power the MAWD from a 9V battery, and the BOE from the 7.2V RC battery. Remember that you will still need a common ground so that BOE will have a reference for the·serial data from the MAWD. A 9V Duracell is rated at 550 mAH, and the MAWD instruction manual says "operating current: 8 Ma typical", so you would hope to get 550/8 = 68.75 hrs of life. Obviously that's very rough, but it has plenty of leeway if you just need 5 hrs, especially as you're not drawing current from the firing terminals (though I suppose it might still use current on those outputs even with no e-matches attached - I'm pretty sure it can't, though, as it's an open circuit there).
I also think that if you're measuring altitude and a couple of gas concentrations, one or two readings per second should be just fine, especially, again, since you're not interested in the data on the way up (the part of the flight at which things change very quickly). If it were me, I'd put my effort now into making the system bullet-proof rather than into trying to increase the sample rate.
I don't know what went wrong with that flight of mine that crashed. In a few days I'll test the altimeter, and see if it's still good. It's a Perfectflite HA45, the only one of those that I have. The battery seemed to be still in place, and I did check the arming switch, and it was armed (I though I might have forgotten to arm it - that happens pretty often, though I haven't done it yet). The battery is still putting out more than 9V, even though it's not really rectangular anymore
I've been away over the weekend at Pt. Reyes Nat. Park and blissfully away from keyboards and screens!
I don't think you should spend "big bucks" to update to another Stamp. Stick with what you have. There isn't much time left! On the other hand, a backup BOE is always a a good idea.
You said the Rocketeers connected the BOE and the MAWD in series to the battery, and I gulped, "oh no!". That won't work, but you already know that. But then, "We also hooked it up in parallel, with the same results.", which I find hard to understand. I think there must have been something miswired there too. It should be possible to supply power in parallel to the BOE and the MAWD, as per the attached diagram. Or, you can use a separate battery for the BOE and the MAWD, as Sylvie points out, and be sure to note the statement about the common ground.
If the program is working fine and already records data fast enough, I agree about leaving well enough alone. Better to focus on the "bullet proof" part. The anomaly in your first "static test" is troubling, why did it stop taking data after a duration of 7:26 instead of at the total clock time of 11:21? That could be one of those things that go bump in the night, something that you don't want to happen during a flight.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Let me try this again.The internet just ate a long reply without posting it...!
We're away·on college visits for several days but we did get the MAWD-BOE Air Sampling Probe assembled before we left. We also did·more battery testing, with encouraging results. The BOE ran for 15-1/2 hours connected to the Ni-MH rechargeable battery and it only used 1.2 volts. It gave error-free data and might well have run for another 15 hours. The MAWD ran for 5-1/2 hours on a 9-volt lithium battery and it used less than·one volt. It also gave complete, flawless data. The two weren't connected and they will run on independent power supplies in flight.
The batteries are very securely mounted (bolted) on to one side of the ASP platform and the MAWD-BOE is bolted to the other side (see attached photos.) All connections are soldered and the 9 volt battery is secured with a piece of rubber surgical tubing (the yellow thingy in the photo.) One of the next things we have to do is shorten the plaform so we have more room for parachute(s). We calculate we'll have 2-3/4" to 3" of height·and 5-3/4" diameter. The team is doing more research on parachute bags, parachutes, and descent rates. Although it feels heavy, the MAWD-BOE weighs just shy of 1 kg (2.2 pounds) and we may be able to use a much smaller parachute than we thought.·Ideally we'd like·a descent rate of 10 fps, or less.
Sylvie,
Thanks for the cool launch photo (you at the computer)! So that's the gizmo, huh? It looks fairly straightforward (and you look like a happy camper.) Did you launch over the weekend? When's you're next launch, on what new gadgetry? Doubtful I'll have the chance to launch for at least a few weeks· =(
Christopher interviewed at Swarthmore College today. It's a nice campus with an excellent liberal arts program. From here we'll visit U Penn, Johns-Hopkins, George Washington, Georgetown, American University, Haverford, and Columbia. Then back home where we visit Bowdoin (12 miles from our summer home), Dartmouth, and Tufts (again.) Christopher wants to study international affairs and I think he's on the right track. His interviews have gone·really well so far. Any advice on the college interview process, Tracy or Paul? Any advice on the MAWD-BOE...?
From Philadelphia,
Mark
·
First, is there something holding the 9V battery down? It's hard to tell from the photos - it looks like there might be something across the ends. If not, a zip tie through the board and across the battery will do the trick. OH WAIT - I get it. The rubber tubing folds down over it, and is secured with the screw. Okay. Never mind.
Second, you wrote "The MAWD ran for 5-1/2 hours on a 9-volt lithium battery and it used less than·one volt". That's great, but suggests that you might have a misconception. The volts aren't a measure of the capacity of the battery, at least in the "battery life" sense. For example, if you used 1 volt in 5 hours, that wouldn't mean that you had 9 x 5 = 45 hours of battery life. Take a look here and you'll see how these things are measured:
http://www.powerstream.com/9V-Alkaline-tests.htm
You'll see that the voltage of these batteries drop a little over their useful life, and then suddenly drop like a rock from about 6V to 0V when they're out of juice, as it were.
Saying that a battery has 9V is more like saying that a car will·hold 4 adults than it is like saying that it'll go 300 miles before it's out of gas.
Now, you're apparently getting plenty of life out of your battery, so I wouldn't worry. It's worth noticing (on the page with the tests) that there is significant variation in the lifetimes of different 9V batteries, so don't go changing brands/types from your tests to your actual launch. Launch what you tested.
Third, I see a toggle switch on the board. I assume that the entire thing will be enclosed in a tube of some sort, correct? If not (which would surprise me very much) the toggle switch will be a problem. Those things love to snag shock cords, which flips them to "off". Iron clad rule: toggle switches are not to be mounted on the exterior of a rocket.
Fourth, I understand "Rocket Rage" makes parachutes that pack to a very small size:
http://www.rocketrage.com/
I've always wanted one. It looks like they're all too large though for your purposes. Top Flight (Gary Pletzer, a local guy who I see regularly) makes some really wonderful "thin mill" parachutes that pack quite small. It looks like they come in sizes up to 30" and down to 9":
http://www.topflightrecoveryllc.com/
Fifth - yup, that's me with the gizmo. I'm still trying to gather photos so that Sport Rocketry will have something to publish. I'm sending them a package with the article (revised to cover the second launch) and a CD of photos. Unfortunately, the photo is a little blurry - it's hard to find people who can use a digital camera correctly, even at a high-tech rocket launch.
Sixth: re. college advice - writing clearly REALLY matters. Contrary to popular opinion, we college folks are not at ALL impressed by big words (I rant at students who say "utilize" when they could have just said "use"). We want nice short clear sentences, each of which expresses an idea. Eagerness to learn also matters a lot, and these rocket projects clearly demonstrate that your students have that eagerness.·A demonstrated ability to work in a team on a project that has iron-clad deadlines is also a big plus, and your students have demonstrated that as well.
My dad graduated from Tufts many many years ago, with a degree in physics. In WWII he worked in the China-Burma-India theater on radio beacon guidance systems for our B-29s. Then he came home and went into building automation (to increase efficiency of heating and AC systems in buildings) with Johnson Controls: we were doing "green technology" in my household all the way back in the 1960s, and "going green" put me through college and left my mom with a comfortable pension after my dad's death.
Anyway, International Affairs sounds like a great choice. I wish I'd done something with an international side to it when I was in college, though that seemed like a complete pipe dream to me at the time.·I never really got to travel until I was in my 30s and 40s, though I've made up for lost time pretty well. International travel changes you in a very good way, and if you can change at a younger age, it's that much more valuable.
Finally, I didn't fly rockets this past weekend, but we do have another launch in two weeks. This weekend I went to some minor league baseball games, and watched the air show here on the Milwaukee lakefront: F-15s, an F-18, the Thunderbirds in F-16s, several aerobatics teams, and the Army Golden Knights parachute team. I have the luxury of being able to watch from a nice hill at the end of my block.
This week is the beginning of the Experimental Aircraft Association annual convention, which means that the busiest airport in the world is in Oshkosh, Wisconsin (there's a nice trivia question for your friends). The Airbus A380 - world's largest passenger jet - landed here at the Milwaukee airport today on its way up to Oshkosh. There's lots of interesting stuff in the air around here these days.
I'd also wanted to fly it to about 3000 feet on a J500, but the weather and time didn't cooperate. I'd also hoped for a chance to get out today and try it, but it's raining. Maybe in two weeks, at our big public launch.
I flew the XBee/MAWD again yesterday, twice. First it went up on another I245G, to only 1049 feet in fairly high winds, with good data throughout yet again. Then I got gutsy, and put it up on the J500G. It flew to 2679 feet, and amazingly (to me, anyway), still stayed in contact throughout the flight. The datasheet says it should get a range of 1 mile, but I'm probably getting pretty close to that without any issues, and I generally expect that datasheets give the absolute "best case" estimates. In this case, 1 mile is starting to look completely realistic, given I was almost 2700 feet up and quite a ways downrange.
Unfortunately, my main parachute failed to deploy, and I hit the ground at somewhere over 80 MPH. There's a nice dent in the big capacitor on the MAWD, and I wouldn't trust it to fire ematches anymore (though it was dutifully beeping out the altitude when I got to the landing site). The XBee and board are just fine. The rocket's fin can is now trash, though. I'll have it up and flying on a different fin can by the next launch, in two weeks.
I assume that's·the XBee data sheet? This is a real-time data downlink, yes?
I'm probably getting pretty close to that without any issues, and I generally expect that datasheets give the absolute "best case" estimates. In this case, 1 mile is starting to look completely realistic, given I was almost 2700 feet up and quite a ways downrange.
Bummer that your main 'chute failed to deploy, especially on an expensive rocket with lots of time in it. *I never tell my wife how much the rocket really costs, especially after a crash or a CATO. It's pretty amazing that the MAWD was still beeping out data and that the XBee was intact! I suppos if all you lost was a fin can, you should consider yourself lucky! Excellent altitude graph, by the way.
We figured out the 'pilot parachute deployment bag'. It was really simple to make, and very small. Basically it's a small nylon bag, about the size of a sandwich bag, with a small clip inside to clip to the top-center of the main 'chute. The outside has a small Kevlar loop sewn on, and that's where the 24" pilot chute attaches. We've ground tested it and it seems to work perfectly ("seems" being the operative word.) The launch and receovery will tell all. I really need to get updated pictures posted so you can see.
The team shirts and mission patches have arrived and they look awesome! If you give me an address and a·shirt size·(you too, Tracy) we'll get yours out to you in the mail. Or, if you come to the ARLISS launch... we'll present it to you at the breakfast banquet. Hopefully we'll have lots (of data) to celebrate, and an intact MAWD-BOE-ASP. It's finished, it works very well, and it looks very professional. I'll check in later and post more often.
Mark
Yup, the XBee datasheet says 1 mile of range, and I'm starting to believe them. Those XBees are amazing. You should think about sending your data down by radio link next year instead of onboard logging.
Last night I hooked the MAWD up to the data download software. The data downloaded just fine, and all of the tests worked. I didn't burn ematches on the output test, but it did light the two LEDs I usually use to test outputs. I think that MAWD might still be in working condition despite the dented cap. But better yet, I got the idea of using it ONLY to send the altitude data, and using another altimeter for deployment. I've been looking for a place to use that new Missileworks RRC2, and that's the place.
As for the "great looking altitude graph", I prefer it when the graph levels out a bit at 500 feet.
Congrats on the pilot chute thing. The main chute pulls out smoothly when you pull JUST on the pilot chute, right? That's what matters.
I seriously looked into coming to the ARLISS launch, but unfortunately it's in the middle of a very busy time for me. I'd have loved to have come. I'll PM you a mailing address - thanks!
···· So the MAWD gave you data despite the dented capacitor? That's excellent that it still works. I guess I'd be cautious about using it for primary deployment though, especially on a a primo rocket.
So you can connect LED's to the main and drogue outputs instead of e-matches, to check whether the outputs·work? That's a clever idea. What happens when you draw a vacuum on the MAWD? Do the LED's flicker for a moment at "apogee" and at (a theoretical) "500 foot" altitude? How long do the·LED's stay on? That's a great way to save e-matches!
During TARC we discovered that Quest·sells low-amp igniters that can be ordered by mail. They're inexpensive and they work as well as a regular e-match. I'm not sure how they·might work on larger projects, but there is enough pyrogen on the tip·to ignite virtually any amount of Pyrodex, etc. We simply solder wires on to the igniter wires·to make them·any length we need.
I tried to upload some jpeg's of the finished MAWD-BOE-ASP from (my cheesy, slow dial-up) home computer but it was tooslow and the jpeg's were too large. So I'll take them in to school and post them from there.
ARLISS is sending us·a "Big Red Bee" GPS transmitter to·mount on the ASP so they can transmit real-time data through their Virtual Classroom downlink. It's a long distance (high power?) shortwave transmitter. Question: Do we need to shield the shortwave transmitter from the ASP to prevent possible data corruption?· Is it likely the short waves (electromagnetic waves) could 'zap' the ASP and it's data? The two units will be only a few inches apart.
PM e-mail is mkibler@unity.edu·- It'd be cool if you could make it ARLISS....!
Ciao
I didn't come up with the LED idea myself - I got it from Xavien, which sells a little kit for testing these kinds of devices. The LEDs need resistors, of course: I'm not sure what size they're using, but they work. The LEDs come on as long as the MAWD output is latched on, which is about 1 second.
http://www.xavien.com/
I'm not drawing a vacuum in a vacuum bottle yet for testing: the MAWD software has a couple of buttons to test the outputs without having to simulate flight, and that's what I used yesterday.
The question about the Big Red Bee GPS unit is probably best answered by one of the experts here. For their information, here's the relevant BRB webpage:
http://www.bigredbee.com/BeeLineGPS.htm
It's not technically a "shortwave" device, but rather a 70cm (433 MHz) device, just like their regular transmitter. It requires an Amateur Radio license to operate: I assume the ARLISS people have a Ham among them who can legally use this device? I got my Amateur Radio license explicitly for the purpose of legally using a Big Red Bee transmitter.
Edit: Oh, re. those Quest Q2G2 igniters - yup, they're great. Be careful with them though - some of the continuity checkers on launch systems will set them off. They fire with very low current. If you're using them to light a motor, either get clear before doing the continuity check or test them with your system before putting them into a motor. You do not want to be next to the pad doing a continuity check and have your motor light.
Post Edited (sylvie369) : 9/2/2009 11:15:41 AM GMT
-- Tracy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com