IDEAS? 'On/Off switch' to activate a Datalogger?
Mark in NH
Posts: 447
Hi All,
My students are designing a payload for a rocket that will be launched in the Black Rock desert in September (www.arliss.org; www.wearerocketry.org). The payload measures and record atmospheric data and·we would like it to start recording data as soon as it deploys from the rocket at 12-15,000 feet altitude. It already has a Datalogger, an RTC chip, and a Sensirion humidity and temperature sensor installed on the Board of Education so space is limited.
What simple and elegant suggestions do all you programming gurus have for·starting·('booting up') the Board of Education right·after it deploys?·We're hoping for something·that requires·a limited amount of (re)programming and wiring since space, and meeting time, are limited. These are 8th grade students and I'm certainly not a programmer. So the simpler, the better (Occam's Razor.)
We've considered a touch sensor, a light sensor, a tilt sensor, etc., but we're really eager to hear your ideas. I've attached photos of the current arrangement sensor and wiring arrangement on the BOE, along with a·program·that Tracy Allen, Mike Green, Phil Kenney and other Parallax friends wrote to get the gizmo to record data to the Datalogger. Thanks for your speedy and numerous·replies.
L. Mark Kibler, M.Ed. - Mentor, ARLISS Team New Hampshire
Thomas Zervos, Mollie Dowst, Sean Doherty, Andrew Mahn, Jessica Chapman, Chris Kibler, Tyler Becker
Attachments
My students are designing a payload for a rocket that will be launched in the Black Rock desert in September (www.arliss.org; www.wearerocketry.org). The payload measures and record atmospheric data and·we would like it to start recording data as soon as it deploys from the rocket at 12-15,000 feet altitude. It already has a Datalogger, an RTC chip, and a Sensirion humidity and temperature sensor installed on the Board of Education so space is limited.
What simple and elegant suggestions do all you programming gurus have for·starting·('booting up') the Board of Education right·after it deploys?·We're hoping for something·that requires·a limited amount of (re)programming and wiring since space, and meeting time, are limited. These are 8th grade students and I'm certainly not a programmer. So the simpler, the better (Occam's Razor.)
We've considered a touch sensor, a light sensor, a tilt sensor, etc., but we're really eager to hear your ideas. I've attached photos of the current arrangement sensor and wiring arrangement on the BOE, along with a·program·that Tracy Allen, Mike Green, Phil Kenney and other Parallax friends wrote to get the gizmo to record data to the Datalogger. Thanks for your speedy and numerous·replies.
L. Mark Kibler, M.Ed. - Mentor, ARLISS Team New Hampshire
Thomas Zervos, Mollie Dowst, Sean Doherty, Andrew Mahn, Jessica Chapman, Chris Kibler, Tyler Becker
Attachments
467K
1280 x 960 - 474K
Comments
2) How is your payload going to land? How is it deployed from the rocket? Simpler is always better, particularly for something as basic as turning on your payload. What do you have in the way of spare I/O pins? Basically, there ought to be a way to mechanically sense when the payload is deployed and have that activate a switch that the program can sense. Can the power to the payload be turned on as it's deployed or does the payload need to be running before that?
What's a really good, long-lasting (9V ?) battery·we·could·use to power the BOE? It could be running for several hours before we find it after touch-down.
How easy (difficult?) would it be to integrate an accelerometer on to the already crowded BOE board so we can correlate altitude with flight time and gas concentration?
Thanks!
You'd need both an accelerometer and a gyroscope to calculate position (since your setup will undoubtedly rotate). You'd also have to take and store samples really quickly to get a good estimation.
It wouldn't be too difficult to throw out all the bad data that recorded on the launch pad and on the way up. You could simply make a plugable wire or contact that when the module is in the rocket it reads high, then release breaks that contact and the module marks "release" into the datafile.
Also, once release occurs, the module could record data for 20 minutes or so, then shut everything off. You don't really care if it runs out of battery power at this point, since all the data is stored on the USB drive.
Thanks for your post. It's good to be back on thr forum again. The photo of the BOE wiring is the prototype model. The wires on the 'original' ASP (air sampling probe) are secured with clear silicon 'caulking'. The Datalogger is epoxied on to a small piece of G10 fiberglass that's epoxied to the BOE. This arrangement withstood over 15 G's at liftoff last April at NASA. We (I) haven't yet mastered the fine art of soldering the final project onto a 'real' PCB.
How challenging would it be to put an accelerometer on the BOE and then modify the current program to datalog the altitude so we correlate it with time, temperature and humidity?
Mark and the Rocketeers
I agree with SRLM, you will need an accelerometer and a gyro to accurately calculate the position of your rocket. I actually completed a similar project for Senior Design my last year of college, except we were mapping the rocket's flight pattern. Since we were wirelessly transmitting the flight data, the rocket sat on the launch pad for quite some time before we verified everything was working correctly. We ended up simply deleting the data before graphing it since it was easy to tell when the rocket began its flight (and used a lot of 9V batteries).
Another, albeit crude solution would be to use the SLEEP command to keep the rocket in low power mode for a certain period of time before the launch. This can be a pre-determined amount of time based on how long it takes the students to set up for the launch. Since it will only take a couple of seconds for the rocket to reach its apogee, that's not that much data you will have to worry about throwing out. Then as SRLM said, after awhile put the rocket back into sleep mode to save battery (it will probably only take a few minutes for the rocket to land). As I mentioned it's a rather crude solution, but it will prevent you from adding more hardware and code, since you mentioned you were short on time.
A pressure sensor will also get you altitude information - Parallax does not currently stock one, however, and I am unsure of one offhand that is breadboard friendly.
For more information on the SLEEP command, check out the BASIC Stamp Syntax and Reference Manual.
Hope this helps,
Jessica
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jessica Uelmen
Education Department
Parallax, Inc.
Hi I am one of the students with Mr.Kibler and I was wondering, what exactly does the gyro do, and how does it interface with the accelerometer? Do you think we would have enough space on our current BOE (see picture above)? Thanks everyone for your replies.
Sean
Also, Sean, you can make an account and post as yourself on this forum. It's free, and it will help us (me in particular) keep track of who's who.
It's Sean, I am with Mr.Kibler. I thought I had already logged out and logged in as my account, but I guess I didn't. Sorry for the inconvenience. Thank you for your replies.
Thanks for your suggestions. Will·an accelerometer and a gyro fit on the (limited) space we have left on the BOE (see attached diagrams we posted previously)? Also (though I'm sorry to say)·re-wiring all the sensors and re-writing the program is at the far edge of our abilities,and our time constraints. I'm an 8th grade science teacher with very limited programming skills; this is the first introduction to programming for most of·the students involved with·the project. Also, our practice and building time is limited to seven, 3-hour sessions. We're looking for a simple, understandable, cost-effective solution to activate the BOE at apogee, and a way to correlate the data we collect with altitude.
Though you say it's a crude solution, I like the idea of using·a SLEEP command to shut down the BOE after it· lands. The payload that comes out of the rocket·(and which the BOE is mounted on) is made from two, 5-3/4" diameter, 9" long·wooden circles with a flat piece, 3/8" thick piece·of wood·connecting·them. The batteries, shortwave tracking device, parachute, etc. all mount on the flat board (about 5" wide x 9" long x 3/8" thick.) I'll ask Thomas or Sean to upload a picture of the payload device.
We also have an off-brand (PerfectFlite MAWD) altimeter mounted on the payload board. It records altitude and total flight time beginning at lift-off. If there was some way to interface the MAWD (mini-altimeter with deployment) with the BOE (to have the BOE 'read' the MAWD data), that would accomplish what we're trying to do.
It may be helpful to know that the MAWD·is designed to output·a short burst of electricity at apogee (to fire a parachute ejection charge, etc), and another 9-volt burst at a pre-set altitude on descent (500', 1000', or whatever we choose.) I'm·think there may be a way to use this to 'start' the BOE; I just haven't figured out how!
Thanks for all the idea. We enjoy reading them, and all the professional dialogue.
Regards from New Hampshire,
Mark - ARLISS Team New Hampshire
No, it won't fit on what you have. It also probably won't fit in your budget (~$200). But, the point was was that you can't use just an accelerometer to determine position/altitude.
Probably the best solution available would be to have the BS2 monitor a pin for the burst from the altimeter, and to immediately start sampling 20 times per second (if that speed is possible). From the datasheet (here) it doesn't look like the device actually outputs anything. You may want to monitor the RX port and see if it outputs the altitude in flight, but that's probably a fool's hope.
You could connect the burst output to the BS2 through an appropriately sized resistor. I have no idea what the value would be: I'd determine that empirically.
Last year, didn't the rocketeers have a wood dowel pushed into a phone jack or switch, so that when deployed from the rocket the dowel would pull out and boot up the system? Is that right? Did it work?
I don't think you have an vibration or tilt sensor, or an altimeter, and it sounds like space and time and cost will not allow you to add one now. You do have temperature and humidity sensors, and there is that LED that you can use also as a light sensor if it is positioned to see the sky. When the rocket is sitting on the ground, those parameters are going to be relatively stable, but once launch occurs they are going to start changing. Changes could signal time for intensive monitoring.
A clever rocketeer might rig up a hair trigger on a couple of the free Stamp IO pins next to the LED. A mass on a piece of spring wire to make or break an electrical contact.
I agree with Jessica about SLEEP. It is not crude at all. Very sophisticated systems use that technique to save power, to check at intervals for events, and to come fully operational when events occur. For example, the Stamp could wake up once a second and check the the temperature or light level or a switch and then start data logging when it detects a big enough change.
The SLEEP option works best when the system can truly power down. The memory stick data logger is a bit of a problem in that respect, but I think it is manageable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
It's good to hear from you and it's great to be back on the forum with another project. Yes, last year we did use a 'dowel' inserted into a phone jack to activate the robot (when the dowel is pulled out.) But (borrowing Jess' words) it seems like a rather crude approach not befitting a programmer. If we use the same mechanism this year it would require us to route the Kevlar string (that pulls the dowel out of the jack) in and around the parachute and some other hardware... a somewhat crude, but effective, approach.
Can you explain how the "hair trigger" idea on the I/O slots next to the LED would work? Does the mass object physically pull the spring wire out of the I/O slot (which essentially acts as an on-off switch?) Would the mass object tumble through the air...?
If the memory in the Datalogger/ flash drive is non-volatile, how important is it to power down the BOE after it deploys and lands? Our biggest and most important challenge is accurately correlating the data we acquire with altitude.
One of the team's five 'missions' this year is to add and program at least one new sensor. If we were to choose one new sensor to add and program to inteface with the current configuration on our BOE, which would you suggest? I think you grasp our constraints: time and talent.
It's good to hear from you again Tracy. I hope you received our package in good order. We really appreciated all of your help with our last project and we look forward to this year's dialogue,and learning.
Regards,
Mark and the Rocketeers (v 2.0)
Just wanted to let you know I'm following this thread.
Thanks,
Andrew from NH
http://www.rocket-roar.com/rap/alt.html
cheers, David
Very important. If you're writing to the datalogger when power is removed it's possible to corrupt the whole file.
http://wooshrocketry.org/WOOSHPop/WOOSHPOP200807.pdf
The BOE's serial port can be set up to read incoming serial data. The MAWD output is at 9600 baud, and cannot be changed, so you may run into some issues trying to keep up with the incoming data at that speed (look at the documentation for the SERIN command in the PBASIC manual). Using a faster Stamp (2p or 2px) may help out. I turned telemetry on using a button in the MAWD Data Download program. You will probably need to do it that way as well (rather than as part of your Stamp program), because serial communications for the commands to the altimeter have to be at 38,400 baud, which is far too fast to be used by a Stamp. Fortunately, the "Telemetry On" function is stored in non-volatile, so it'll stay on until you explicitly turn it off.
I know that Adrian of Featherweight Altimeters (the "Parrot" line) uses one of his altimeter outputs to turn on a radio transmitter:
http://www.featherweightaltimeters.com/
I'm not sure if that could be done easily with a MAWD output, particularly if you're trying to use the same output to fire a charge. But if you can read the MAWD altitude data into the Stamp, you could simply start your datalogging as soon as the altitude starts decreasing again (say, average over 5 altitudes throughout the flight, and as soon as the average starts dropping, start recording).
Post Edited (sylvie369) : 6/10/2009 4:38:20 PM GMT
How about that TARC rocketry·team from Mad-West? NATIONAL CHAMPIONS! Way to go!
Your comments and links about using·the MAWD are interesting. We'll have to read them to see if the idea is manageable. You said:
"I turned telemetry on using a button in the MAWD Data Download program. You will probably need to do it that way as well." Can ypu explain what, or where, the 'button' is? Any other ideas or suggestions?
Mark
The topic, "'On/Off Switch' to activate datalogger" could mean a couple of things. Last year the clever dowel in phone jack trick worked to turn on the whole system, including both the memory stick datalogger interface and the BASIC Stamp/sensors. The memory stick datalogger is the component that draws the most power. So the On/Off question could also mean to control the memory stick datalogger by means of a command from the Stamp, and let the Stamp itself run with low power in SLEEP mode while monitoring for takeoff.
I personally favor the latter approach. A standard 9v battery with 600 mAh could easily handle the whole mission, and the Stamp could turn off the memory stick interface and go back into SLEEP mode at the end of the mission.
It is not too hard to implement control of power to the memory stick datalogger from the Stamp. It takes one transistor, and I think it could fit it on your circuit board. One desirable side effect is that managing the memory stick data logger in software is much easier if you can control its power supply.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
-Jess
The "button" I'm referring to is in the Data Capture software (which you can download from the Perfectflite site), under Altimeter/Setup. Alternatively you could hook the MAWD up to a serial port, open a terminal program connecting to it at 38,400 baud, and issue the T1 command, which turns telemetry on. I may play with this a bit more and see if I can get it to send data to a Propeller (or a 2px Stamp).
·· I'm intrigued by the idea of connecting the MAWD to the BOE through the·serial port and having the BOE 'read' the data. Do you think it will work? The MAWD's data download cable has four wires I believe. How do you know which (and how many) wires to connect to the BOE (and where) without·short-circuiting either one? How·is the MAWD data be converted into readable language on the BOE?
To quote from Pistachio Disguisi in 'Master of Disguise': "That's a crazy idea. So crazy that it just might work!"
Aim high,
Mark
I posted a link to the datasheet up above, and it shows the pinout...
http://68.178.208.82/cgi/PF_Store/perlshop.cgi?ACTION=thispage&thispage=DT2PM.html&ORDER_ID=169380360
It will plug into the serial port of the BOE (you'll need a gender changer since both cables have female ends...*but see below*). Then you just read the data through that port using SERIN commands. Now, that's the theory: I haven't done it yet. I've just read the data using a terminal program. The extra challenges are (1) using SERIN at 9600 baud on a Stamp module, and (2) parsing the data that come in. What the MAWD puts out, I believe, is just 5-digit numbers representing the altitude, separated by CR/LF. You should be able to wait·for a CR/LF (see the documentation for SERIN), then read the next 5 digits into your "altitude" variable, and you're good to go.
Alternate idea: I see that the serial dongle they're selling now comes as a cable with a connector on both ends, and a separate converter/RS-232 jack. I assume that separate converter is a TTL->RS-232 circuit, which of course you don't really need, since the Stamp is perfectly happy reading TTL directly. You might buy that dongle, but just use the cable, and go straight into an input pin. You might want to confirm first with Perfectflite that what's coming out is TTL-level (you could do it with an O-scope as well, I suppose). Attached is the pinout (from the manual, as SRLM noted). In fact, now that I look at it, this would be the much easier way, I think. My older serial dongle was all one piece, so I had to use the RS-232, but it's pointless to convert to RS-232 on the dongle and then right back to TTL on the BOE.
Now you've got me wondering if this could be connected directly to an XBee. I bet it could.
Post Edited (sylvie369) : 6/11/2009 11:02:56 AM GMT
Thanks for the pin-out JPEG. I'll have to look at it again to be sure I'm connecting the right wires to the right input(s) on the BOE. Do you know specifically which wires go into exactly which input slots on the BOE? That would be helpful so taht we don't toast all of our electronics; how much of a risk is that?
Sylvie,
I'm wondering how the dual-deployment function on the MAWD might disrupt altitude data flow to the BOE·(or not.) I was musing over this last night and it seems like this idea would also work with the simpler PerfectFlite ALT15K, which only records altitude. Either way, I think we're on to something here.
Where do·we begin? Should we go ahead and plug the wire into the MAWD and then simply connect individual wires into the BOE input slots (which ones) to·see what happens? I'm not an electrical engineer nor do I have (or understand) an oscilloscope.·Visualize a·fairly generic 8th grade science·lab-- and my basement full of rocket gear-- and that's essentially what we have to work with (which is why I value·everyone's·input greatly.)
So where do we start?!
Good morning from rural New Hampshire,
Mark
This is great, and it looks like it might well work. Are you tinkering with the same configuration (hardware and software)?
I was musing about this last night and I wonder if, and/or how the dual-deployment function on the MAWD might affect the altitude data flow (or not)? Would it be simpler (less problems?) to use the PerfectFlite ALT15K? It has the same output connection and it uses the same wire as the MAWD. But it doesn't have the dual-deplyment function. Just altitude data.
SRLM,
Thanks for posting the pin-out JPEG. I'll muse on this to figure out how to connect the two devices. Do you think it's 'safe' to go ahead and plug the MAWD wires into the BOE input slots "to see what happens?" Will I toast the circuit boards?
Mark
10 kOhm resistor MAWD telemetry tx ------/\/\------- Stamp input pin MAWD telemetry GND --------------Stamp VssAs was pointed out, the Stamp can have trouble receiving data at 9600 baud, depending on how it is paced out.
Attached is a photo of how I hooked up a p-channel mosfet to control the power to the memory stick datalogger. As you see, the transistor replaces the wire that goes from Stamp Vdd over to pin 3 on the dataLogger. The gate is controlled by Stamp p15. The datalogger is a relative power hog, and your battery will last longer if the PBASIC program can turn the power on at launch. The rest of the system could rely on SLEEP for power conservation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I don't think that the ALT15K is going to work, because I don't see any sign that it does telemetry. I've got one of the older models of that as well, and I am almost certain that it does not do telemetry. I think you're going to have to stick with the MAWD, and I don't see any real disadvantage to that anyway. The MAWD's firing of output channels doesn't directly disrupt telemetry output, though I suppose the shock from a charge going off might (but you're going to face that anyway). The MAWD is only $25 more than the ALT15K, and does so much more. I'd stick with it.
I just ordered one of the new data download cables, so I can play around with getting a Stamp or Prop to directly read the MAWD's (presumably) TTL serial output. If that works, it's only a short step to building a setup where the MAWD's output is sent by radio down to a base station that displays rocket altitude in real time, which is one of my long-term project goals. I'll let you know how that goes.
Edit: Oops - I just found my old download cable, and sure enough, the connector·IS removable from the serial converter part. The chip on the converter is one of these:
http://www.national.com/mpf/DS/DS14C232.html
which I believe is a MAX 232 knockoff. Unless I'm sorely mistaken, that means that the input from the cable will be nice well-behaved TTL level 5v, so I'm going to take a chance and connect it through a 10K resistor to a 2px chip's inputs, and see if I can read the data from the MAWD. Hopefully I'll have some time tomorrow or Saturday to try it.
Post Edited (sylvie369) : 6/11/2009 4:48:58 PM GMT
This is Tom. I'm with ARLISS - Team New Hampshire, and I have a simple question. This is my first year with the project.·When we put the BOE to·SLEEP we thought that all the lights would go off. when we program it to SLEEP,·the green·BOE power·light is still lit. The red·datalogger light and the blue·flash drive·light stay·on. Are the lights supposed to go off during SLEEP command?· Do you want us to upload the program to see if we are using the SLEEP command correctly?·
I appreciate all your replies,
Tom
The BOE voltage regulator itself will draw a couple of milliamps of quiescent (minimum) current, but it is not much and can't be helped without a big redesign. Low power design is a whole field of engineering, one that has taken off in the last few years especially due to the proliferation of ever more capable handheld devices.
Now, the really big power hog is the memory stick data logger. Only the BASIC Stamp goes to SLEEP, not the logger. That was the point of my previous post with the mosFET transistor. The BASIC Stamp can possibly turn the logger ON only when it is needed. The logger draws surges of current, when it writes to the flash card, so the battery has to stay in really good condition.
The real time clock and temperature/humidity sensors do not draw much power.
Last year you connected the power using the pull-out launch switch. If you want to use the Stamp SLEEP command instead, then you will need means to manage the power.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com