I don't think that anything on the BoE is going to blink while you're receiving data. I get blinking on the USB/RS232 adapter I use (as it sends data to my computer), but nothing on the Carrier Board. If the BoE normally blinks to indicate serial I/O, that's in response to data going through the board's serial port (and pin 16), not a separate wire that you're attaching to a Stamp I/O pin. Here's the relevant information from the Stamp manual:
Stamp Manual Author Person said...
All BASIC Stamps (except the BS1) have a line receiver on its SIN pin (Rpin = 16). See the "Hardware" section of the "Introduction to the BASIC Stamps" chapter. The SIN pin goes to a PC's serial data-out pin on the DB-9 connector built into BASIC Stamp development boards. The connector is wired to allow both programming and run-time serial communication (unless you are using the Stamp 2 Carrier Board which is only designed for programming). For the built-in serial port set the Rpin argument to 16 in the SERIN command.
All BASIC Stamps (including the BS1) can also receive RS-232 data through any of their I/O pins (Rpin = 0 - 7 for BS1, Rpin = 0 - 15 on all other BASIC Stamps). The I/O pins don't need a line receiver, just a 22 kΩ resistor. The resistor limits current into the I/O pin's built-in clamping diodes, which keep input voltages within a safe range.
Two wiring issues: you don't need a resistor between the brown ground wire and the Vss on the BoE. Also it looks as though you have a wire running from the red wire on the download cable to one of your Stamp I/O pins. Remove that as well.
You should have a wire going from the brown ground wire on the cable directly to your Vss, and then one running from the blue TX wire on the cable through a 10K resistor to one of your Stamp I/O pins. That's all.
Post Edited (sylvie369) : 6/15/2009 12:53:07 PM GMT
Mark, I see on your photo that the the blue wire from the MAWD appears to be connected to either p14 or p15, whereas my program as you reposted still referenced p5 for input. Did you changed the pin number to the one actually used?
Thank you for pointing out that the wire was in the wrong place. We will put it in to the SERIN 5 and see if it works. We'll also take the resistor and the red wire off, like Sylvie suggested (Mr. Kibler said he did this really quickly after practice; he knew it might be wrong.)
I have a quick question also. If we left the blue wire in SERIN 14 and changed·your program·to read SERIN 14, it·should work the same, right? Do you have any other suggestions for this?
Just so you know, we decided to use the·pull pin to activate the ASP after apogee.
SERIN 5,84,40,escape,[noparse][[/noparse]STR array/7] ' if you in fact have the blue wire to hardware pin p5
or
SERIN 14,84,40,escape,[noparse][[/noparse]STR array/7] ' if you in fact have the blue wire to hardware pin p14
There is a pattern there! Many commands use one or more BASIC Stamp hardware pins as input and/or output, and the command will contain a reference to the logical pin number. The pins on the BASIC Stamp are pretty much interchangeable, and any pin can be used with just about any command. That flexibility is one of the great strengths of the Stamp. You have to understand, and make sure the pin the hardware is connected to is the same pin logically referenced by the command. Or else, nada, nothing!
·· I'm headed down to NASA Marshall Space Flight Center and Kennedy Space Flight Center for several days; unfortunately, I won't have the MAWD-BOE with me. The ARLISS Team New Hampshire rocketeers will be checking in and logging in with questions, etc., and I will too.
Sylvie,
Here's a link to a feature story about the ARLISS team·that appeared this morning·in the Concord (NH) Monitor (front page news!) It's documentation that·you could use to·support your application for promotion if you'd like:
Thanks for the helpful information and photos about the wiring. I thought I had it wired wrong and I was skeptical about putting the resistor on the brown wire. But I saw that you had use two resistors and that you had the red wire connected, so I did. I'm eager to get the MAWD wired to the BOE so that it WORKS when I get back!
Mark ·
Oh, sure, get us all wired to see this work, then run out on us!
I'm looking forward to hearing about your progress when you get back. I put a little time yesterday into running it through PLX-DAQ, and have a working (though still crude) version of that. The MAWD is attached to an XBee, sends the altitude data to another XBee on that 2px Super Carrier board, which sends the data through PLX-DAQ to an Excel sheet for real-time graphing of the reported altitudes. It seems to work fairly well, as long as the altitude is significantly over that 160 foot "trigger" level. If it just hangs around that level, weird things happen. I think that's a matter of how the MAWD's firmware works, though.
If I can find the time, I'll mount this MAWD in a payload bay with the XBee, and fly this thing in a couple of weeks.
Pavel and the MadWest team should be having a blast at the Paris Air Show anyway. One of these years I'm going to have to get to it:
·· Thanks for sending the nice article about the Mad-West TARC team. I wish we were off to the Paris show with them! What a great group of young rocket scientists, and mentors. Pavel's a real charcter, isn't he? He said you can still see·his burned-off area from space with Google Earth!·You should have seen him at TARC nationals, pacing like a nervous hen, watching the last scores go up, then finding out they·had won the national championship. I'm sure you had your hand in the pie somewhere too, so you share their victory. I think in a way, we all do. These projects and successes certainly aren't one-man (or woman) productions. The MAWD-BOE-ASP certainly isn't.
It was hard to table the MAWD-BOE and pack for this morning's trip to Marshall Space Flight Center. I almost included all the Parallax gear: multiple BOE's, wires, resistors, power supply, tools, etc. But looking at the itinerary it seemed like there would be·little uninterrupted time to do much more than connect the wires·to their <proper> inputs (plus,·the bell jar and vacuum pump would have been hard to pack!)
I can't wait for the school·year to end (June 29th...!) so we can immerse ourselves in the MAWD-BOE·and get it fully functional. Hard to believe that we only have five, 3-hour practice sessions scheduled before we head to Nevada in September to launch. My son and I will do most of the tinkering and troubleshooting between practices, with your and Tracy's guidance, with some of the Rocketeers popping in as the time allows. Many of them are attending 5- and 6-week long advanced study summer programs as a direct result of their involvement with these projects (and some received full scholarships to attend) so you can't fault them for not being here at every beck and call. So it goes. Welcome to the 'real' work on engineering design, and the challenges of being on a design team.
I'll check back in evening·from Huntsville; the kids should be checking in today sometime. Thanks for your patience and tutelage!
·· Thanks for sending the nice article about the Mad-West TARC team. I wish we were off to the Paris show with them! What a great group of young rocket scientists, and mentors. Pavel's a real charcter, isn't he? He said you can still see·his burned-off area from space with Google Earth!·You should have seen him at TARC nationals, pacing like a nervous hen, watching the last scores go up, then finding out they·had won the national championship. I'm sure you had your hand in the pie somewhere too, so you share their victory. I think in a way, we all do. These projects and successes certainly aren't one-man (or woman) productions. The MAWD-BOE-ASP certainly isn't.
I can't claim to have had any part in the MadWest·team's success, though a couple of other guys in the club (WOOSH) can. However, I was one of the guys who fought that fire that Pavel started, and that oughta count for something. My shovel still has the burn marks, and I wish the Skidmark had never been invented (though he lit his fire with just two Estes C motors, in the engine pods of a plastic model SR71, at the end of one of our contests). I think the brown streak running down from the runway in the attached photo is the remains of that day.
The only reason I'm at the Parallax site at all is that the University School of Milwaukee group used Stamps in one of their SLI endeavours, and those guys (Spencer Graves in particular) brought me into the fold (they took me to Vernier.com as well). What a great education those kids are getting with this stuff. Spencer Graves is the next Werner von Braun (without the bad side). Brilliant kid.
·I have a question. You were talking about a 2px Super Carrier board earlier, and I was just wondering what a 2px Super Carrier board is? Also what does it do? Is it like the Basic stamp or is it different?
Thank you all for your replies and we appreciate all of your help.
You might be able to make do with one of these instead of putting a much more expensive BOE into the air. It's a serial interface rather than a USB, and there are no Servo headers, but otherwise I think it's pretty much the same as the BOE. Maybe I'm missing something, though.
Sylvie, · Another question, if we did do one of these instead of the BOE, would there be a lot of programming involved? Would it be easier to do this or to do the BOE? · Appreciate all of your help. · Sean from ARLISS-NH ·
The carrier board is just different hardware, but you can use the same software (assuming you move you BS2 from the BOE to the carrier board). You'd have to have some soldering tools handy though, but it should withstand the pressures of launching much better than the solderless breadboard. You'd also need a serial port on your computer or a USB to serial converter. If you use the BS2px that's sylvie's second link then you'll need to change a few things in your code that's timing related.
I'd go with the carrier board for this type of project.
SRLM said...
The carrier board is just different hardware, but you can use the same software (assuming you move you BS2 from the BOE to the carrier board). You'd have to have some soldering tools handy though, but it should withstand the pressures of launching much better than the solderless breadboard. You'd also need a serial port on your computer or a USB to serial converter. If you use the BS2px that's sylvie's second link then you'll need to change a few things in your code that's timing related.
I'd go with the carrier board for this type of project.
Edit: sorry to steal you thunder sylvie...
You took the words right out of my mouth. There's no programming difference at all, unless you use a different flavor of Stamp (e.g., BS2px instead of BS2).
You could put a solderless breadboard onto the Carrier board instead of soldering, but as SRLM pointed out (accurately, as always), a soldered version of your hardware will hold up better to the jolting around it'll suffer through (more so on ejection charges than on launch).
If I were you I'd seriously think about going to the Super Carrier board, unless you're using the Servo connectors on the BOE. I'd rather launch a $20 part than an $80 part.
Sean,
You asked about the "2px Super Carrier board", and I just wanted to add my opinion. The super carrier board would be great, but you know that it can be used either with the original BS2 that you have now, or with any one of the other 24 pin Stamp modules. The BS2px is the fastest Stamp module, but it also draws the most electrical current and I would not recommend it for this project where you want to be sure that your battery lasts through the mission. Either stick with your BS2, or if you do find you need more features and program memory, then consider the BS2pe, which is designed for low-power data logging.
I defer to Tracy on these issues, but I do wonder if power is going to be as big an issue as you think. Flight time will be a couple of minutes - probably something on the order of 4 or 5 minutes, I'm guessing, though I've never flown to 15,000 feet. It'll certainly be well under a half hour. It's reasonable to think that the rocket might sit on the pad after arming for something like 15 minutes, but hopefully also always less than 1/2 hour. It's bad practice for several reasons to leave an altimeter powered up in ready mode for longer than that.
That means that the batteries should never have to supply more than about an hour's worth of power to the systems. Now, again, Tracy is the expert, and I defer to his judgment, but wouldn't even a simple 9V alkaline be more than capable of supplying that, even to a 2px?
One possible flaw in my reasoning: the rocket will sit on the ground after the flight for quite a bit longer than the flight prep and flight itself. If the datalogger needs to be manually turned off to close files properly, battery life is an issue. It does seem to me, though, that the whole thing should be programmed to close the files at the end of the flight (e.g., after 20 consecutive readings of "00000" for altitude?).
Now if they don't need the 2px's speed, this is a complete non-issue, of course. Re. the 2pe, isn't the "data-logging" advantage of that chip it's extra EEPROM? It's not much faster than the BS2, and draws five times more power (though less than a third of what the 2px draws). If they're using the USB datalogger, I don't think they need the 2pe, unless they're going to use it _instead of_ the USB datalogger.
Good point you have, power may not be an issue here due to the short deployment. I tend to be paranoid about having an adequate power supply. The BS2px draws 55 mA, and the USB datalogger + SD card if not in one of its power saving modes uses about 80 mA peaking up to 150 mA when it writes to the card. It is not forgiving of brownouts. The BS2 on the other hand draws only 2 mA. If counting milliamps, that is significant. The capacity of a 9v battery is around 600 mAh, so on the surface of it it should get around 6 hours of life at 100 mA drain, but that rating is based on an end of life of around 5 volts. I'd not want to let it get below 8 volts on this system, to supply peak current demands.
One data logging advantage of the BS2pe comes when a program makes extensive use of the SLEEP and NAP commands to save power. The BS2pe wakes for only 0.18 milliseconds to check status, compared with 18 milliseconds for the other stamps, including the BS2. Another advantage it shares with the other BS2p Stamps is all the extra commands, scratchpad ram, and program memory. That would be a help if the rocketeers need to expand their program or add other sensors.
I do think the BS2pe would be a good alternative, to log the data in its eeprom instead of on the USB datalogger, and thus avoid certain power supply and mechanical issues.
Mr. Allen, How would we get a BS2pe if we happened to use one? Would we have to buy it? Also you said that it logs the data into an eeprom, what is an eeprom? Is it pretty much like the memory holder? Thank you all for your replies. Sean from ARLISS-NH ·
·· You've asked some good questions and I see you've received some expert advice on behalf of the team. Thank you for doing your part while I'm at Kenedy Space Flight Center, and for taking a leadership role.
You may want to mention to Dr. Allen and Sylvie and SRLM and our friends that·we do have a limited amount of space on the 'Pod'. Will there be enough space for a different circuit board? What size is·the proposed new board·(you can look that up on the Parallax website)? Do we have enough funds in our budget, and ample time to re-wire the new ASP?
Sean, please e-mail your teammates and ask them for a definitive answer:·high is the rocket going? It gets really cold at 40,000 or 50,000 feet! How will that affect battery power draw, or power drain? Is there water vapor (ice crystals) 'up there' that might affect the ASP? How? Should we insulate the ASP if we launch to 50,000 feet?
Good work, young rocket scientist! Be sure to check the website (below) that I e-mailed everyone earlier today about the Florida Space Grant team's high-altitude project. Some of their engineering concerns are also our concerns. Maybe they have an answer already... or maybe not!
Contact Mr. Eppig, project director·at
> ·reppig@mail.ucf.edu
FYI, yesterday we went right out to the space shuttle while it was on the launch pad, ready for its July 11th launch! Sean, you share this possibility. Keep working diligently, and keep asking (and answering!) the questions you pose.
Right now you are using the original BASIC Stamp 2, the one in the center of the bottom row in the attached picture. It is one member of a family of BASIC Stamp modules that Parallax sells. The BS2pe is in the top row. It is next to the BS2px, which has also been mentioned in this thread.
The BS2pe is a different thing from the BS2 you have now, and yes, you would have to buy it (from Parallax) out of your project budget. I hasten to add that I am not suggesting that it is something that your team needs to rush out and do. Not at all. Making any changes in a working setup is a big deal and you should weigh the pros and cons. I'm more inclined to suggest that you stick with what you've got.
Eeprom stands for "electrically eraseable programmable read only memory". A mouthful, and kind of a contradiction in terms. How can it be read only, programmable and electrically eraseable all at the same time? There is an interesting history there, but your guess is correct, it is a "memory holder". It is the type of memory that holds the program that is running on the green BS2 that you have now.
There is 2048 bytes of this EEPROM memory on the BS2. The other members of the Stamp family have larger amounts, and the BS2pe has the most, 32768 bytes. That memory can be used partly to store a program that you write in PBASIC and any left over can be used to hold data such as ASP data you collect during your launch. At it stands now, your program is storing the PBASIC program in the EEPROM on the BS2, and the ASP data on the USB datalogger memory stick.
I hope that helps.
Maybe Mr. Kibler will be in Earth orbit the next time we hear from him!
Another way to think of the EEPROM is that it's a table (one column, many rows) that can store "snapshots" of a variable or a series of variables at a particular moment in time. Of course, this is just an analogy, and hence it's more of an idea than a technical description.
I really like the idea of using a BS2pe or a BS2px. I think the biggest advantage of changing the stamp would be the bigger EEPROM, of course. However, I don't think the cost of the stamp is as important as how much time we have. Do you think we could really create/modify our program in time?
Also, are the stamps interchangeable on our Board of Education? Can the BS2 easily be removed and replaced with another stamp, such as the BS2pe or BS2px -- or would we need to order a new board?
Andrew said...
Also, are the stamps interchangeable on our Board of Education?
For the most part, the stamps are electrically interchangeable (identical pinouts). The exception is the BS1 (different model) and the BS2p40 (too big). You'd have to adjust your code if you change to any other model besides a BS2e.
As for being able to modify your program in time, it all depends on how much time and effort you're willing to put in, and what you want to accomplish. For the most part, you could just time critical commands as show in this thread.
As I understand it, right now the plan is for you guys to record the data on the USB datalogger, so you're not using the BS2 EEPROM at all. If you stick with the datalogger, then the additional EEPROM of the BS2pe is irrelevant, since that's not where you're putting your data. If you do decide to store the data in EEPROM, I'm sure you'll want that extra space. However, that will require writing code to put the data there rather than on the USB stick.
Now on the plus side, I think it's considerably easier to put data in EEPROM than to use the USB datalogger. Read the pages for the "Put" and "Get" commands in the help file. In addition, it's one less piece of hardware to put up in the rocket (since the EEPROM is built into the Stamp module).
You will have to figure out if the available space in EEPROM will be enough for all of the data you're gathering. That's not really an issue with the USB datalogger, as you'll surely be using a USB stick large enough to hold a LOT more data than you can collect in one flight. With a 2pe you get about 32,000 bytes of data storage area, as Tracy pointed out. Each of your data points will probably use two bytes (since one byte can only hold numbers from 0-255), which means you'll have enough to hold 16,000 data points (* someone else step in here if that doesn't seem right to you *). Let's suppose you have 5 sensors whose values you're recording, and you're taking 5 measures per second. That's 16,000/5/5 = 640 seconds' worth of data (10 minutes and 40 seconds). As you can see, it is quite possible for you to come up against the storage limits of the EEPROM. Actually it's a little worse than that - your program will be using some of that same space, so the bigger the program, the less space you have for data.
By the way, with the BS2 chip has only 2048 bytes of EEPROM, which means 1024 data points (and less, when you count the bytes used up by your program). Even if you had no program in there, that'd be 1024/5/5 = 40 seconds' worth of data, which is obviously not enough.
If you're planning on fewer measurements per second, you can stretch that data space out quite a bit, though. If you did once per second, with the BS2 that'd be enough for about 3-1/2 minutes of flight (again, assuming no program, which is not a realistic assumption) and the BS2pe would give you about 53 minutes' worth of data collection (again, assuming no program).
I'd say that you have to decide how much data you want to collect, and then determine whether or not there's enough EEPROM space on the chip you're using for those data. If not, or if it's looking "iffy", stick with the USB datalogger. You might want to do that anyway, since (if I remember correctly) your group used it successfully last year, and it's sometimes best to stick with what you know.
Just to muddy the waters a bit more, it IS possible to add external EEPROM by attaching additional chips to your board. It's really not that hard, and in the long run, that's what I intend to do when I make dataloggers for flight in rockets. The MAWD altimeter you're using stores its measurements in an external EEPROM chip (a very small one soldered onto the board itself).
An aside: I built a payload bay to hold that setup with the MAWD sending altimeter data out through an XBee radio down to another XBee attached to that 2px chip on the Super Carrier Board. I've put the software (a PLX-DAQ Excel sheet) onto my laptop, and if everything goes right, I'll fly it this weekend on top of a 4" rocket using an H or I motor. I'll shoot for about 2000 feet. I tested it inside the payload bay, and it's working reliably, sending the altitudes to my laptop and displaying a graph in real time.
Of course I could be grounded by weather, or by not having the parts I need. I haven't yet looked at the 4" boosters I have available - I lost my old reliable one to rocket-eating trees last year (along with my first altimeter, a great Missileworks RRC2 that had something like 40 flights on it). I also still have no idea if the range will be sufficient (I'm using Series 1 XBee Pros on both ends, with the little wire antennae).
Sylvie, that's great that the XBee connection is working! Are you using the "pro" or the normal XBee? I guess it will be line of sight all the way, but the "line of sight" is better for the pro.
What temperature would one expect at 50000 feet?
Rocketeers, I looked again at the program that Mark attached to the first post in this thread, which I guess is the final program from last year. It has only 13 bytes of program EEPROM free and 5 words of RAM. But there is a lot of extraneous stuff in there. How is it going to change for this current year, if at all? For example, is it going to have to do the robotic exploration (servos)? Is it going to have to send out messages by Morse code? Are you adding or subtracting sensors or capabilities?
As it stands, it stores data on the USB drive as often as it can get around the main program loop, which has a lot to do with all the movements, sensor reads and writes, and morse code, and I wildly guess it takes on the order of 20 seconds to get around the loop. The USB logger stores 24 bytes in each record. At 3 records per minute, it would take about 7 hours to fill 30000 bytes. That is if the data is stored as fixed field ascii text. If it is stored as binary, then there would be 7 bytes per record.
Assignment for Sean and Andrew: How long would it take to fill 30000 bytes if 7 byte records are stored at 5 second intervals?
Tracy Allen said...
Sylvie, that's great that the XBee connection is working! Are you using the "pro" or the normal XBee? I guess it will be line of sight all the way, but the "line of sight" is better for the pro.
What temperature would one expect at 50000 feet?
Rocketeers, I looked again at the program that Mark attached to the first post in this thread, which I guess is the final program from last year. It has only 13 bytes of program EEPROM free and 5 words of RAM. But there is a lot of extraneous stuff in there. How is it going to change for this current year, if at all? For example, is it going to have to do the robotic exploration (servos)? Is it going to have to send out messages by Morse code? Are you adding or subtracting sensors or capabilities?
As it stands, it stores data on the USB drive as often as it can get around the main program loop, which has a lot to do with all the movements, sensor reads and writes, and morse code, and I wildly guess it takes on the order of 20 seconds to get around the loop. The USB logger stores 24 bytes in each record. At 3 records per minute, it would take about 7 hours to fill 30000 bytes. That is if the data is stored as fixed field ascii text. If it is stored as binary, then there would be 7 bytes per record.
Assignment for Sean and Andrew: How long would it take to fill 30000 bytes if 7 byte records are stored at 5 second intervals?
Mr. Allen,
I think we should be able to remove a lot of code from last year's program. Since the atmospheric sampler will not have wheels, we will not be needing anything regarding movement or the servos. I believe we also made the decision that the Morse code LED (and it's programming) would probably be removed since it would use less power, and less programming space.
"Assignment for Sean and Andrew: How long would it take to fill 30000 bytes if 7 byte records are stored at 5 second intervals?"
If 7 bytes were stored every 5 seconds, it would take just under 6 hours to reach 30,000 bytes of data -- equal to 84 bytes /minute, or 5040 bytes /hour.
Hi everyone, I agree with Mr. Allen, and keeping what we have. The data logger collects data so we wouldn't need more EEPROM on the stamp. Also·we don't have much time on our hands with only four more meetings left. At 30,000 feet it can get as cold as -30 degrees Celsius. I believe that batteries provide lower voltage and drain faster in the cold. Please correct me if I am wrong. Thanks everyone for all your time and help, Tom ARLISS-NH
Are you going to use the dead man switch (dowel in phone jack) to start the logger at the time of ejection?
In general lithium batteries have the best preformance in the cold, but with a little insulation the battery and BOE may not get that low.
It does look like you can save a lot of program space by removing the movement the the Morse code code. That would make room for code to aquire the MAWD altimeter data. It will still do temperature and humidity from the Sensirion sensor, right?
·· Thanks for·your wonderful input, thoughtful questions... and even giving the Rocketeers assignments while I'm here at NASA!
Tracy,
Yes, we·plan on·using the dead-man pull unless a 'better' idea surfaces.·It seems like a simple, low-tech,·funtional solution. You make an excellent point about freeing up space by deleting the robot's servo motor commands and the Morse code commands. I think Thomas made that observation several days ago (good work, Tom.) No motors, no commands needed, right Rocekteers?
If we insulate the BOE we risk inadventently covering up the SHT sensor, which needs air (gas) circulation. My wife e-mailed today to say the Parallax methane sensor came in. It's modular, and it's available as an add-on if space and time (not space-time) allow.
All of you made, independently, a similar and·intersting point about switchng Stamps: it would require a major re-work that doesn's seem practical given our time and budget constraints.
Sylvie, I'm eager to hear the flight status report when you launch your 4" rocket for data acquisition this weekend. I'd like to see the raw data, the read-rate, etc.
On the ride back from Kennedy Space Flight Center to MSFC today, I worked on defining the statistical hypotheses and test(s) we'll be using to analyze the data. The research question, as of this moment, is: "Is there a difference between humidity (or methane) at ground level and 3,000 meters above ground level (AGL)?" I agree wholehearted with you that we need to decide what altitude we are launching to. It's a fundmental engineering question that needs to be resolved as we continue designing and building since·"Form follows function". And, as Thomas pointed out, it's about -30 degrees Celsius at 30,000 feet (about 10,000 meters for Anglophonic engineers.)
Andrew, I met a friend of yours here at Marshall Space Flight Center tonight...!! He gave me something very special to give to you at our next team practice. You also have 'goodies' from Kennedy SFC. I think you're discovering that it pays to be a team leader. Keep up the good work, all of you.
Mr. Allen, You said that lithium batteries perform best in the cold. Do you happen to know how long a lithium battery would last? If we used a lithium battery, would we need to·use an extra battery or do you think·one could last the whole time? Thanks everyone for your time and help, Sean from ARLISS-NH
Comments
I don't think that anything on the BoE is going to blink while you're receiving data. I get blinking on the USB/RS232 adapter I use (as it sends data to my computer), but nothing on the Carrier Board. If the BoE normally blinks to indicate serial I/O, that's in response to data going through the board's serial port (and pin 16), not a separate wire that you're attaching to a Stamp I/O pin. Here's the relevant information from the Stamp manual:
Two wiring issues: you don't need a resistor between the brown ground wire and the Vss on the BoE. Also it looks as though you have a wire running from the red wire on the download cable to one of your Stamp I/O pins. Remove that as well.
You should have a wire going from the brown ground wire on the cable directly to your Vss, and then one running from the blue TX wire on the cable through a 10K resistor to one of your Stamp I/O pins. That's all.
Post Edited (sylvie369) : 6/15/2009 12:53:07 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Thank you for pointing out that the wire was in the wrong place. We will put it in to the SERIN 5 and see if it works. We'll also take the resistor and the red wire off, like Sylvie suggested (Mr. Kibler said he did this really quickly after practice; he knew it might be wrong.)
I have a quick question also. If we left the blue wire in SERIN 14 and changed·your program·to read SERIN 14, it·should work the same, right? Do you have any other suggestions for this?
Just so you know, we decided to use the·pull pin to activate the ASP after apogee.
Thanks, from the lab,
Tom, Sean, and Jessica -Team ARLISS-NH
You can do it either way.
SERIN 5,84,40,escape,[noparse][[/noparse]STR array/7] ' if you in fact have the blue wire to hardware pin p5
or
SERIN 14,84,40,escape,[noparse][[/noparse]STR array/7] ' if you in fact have the blue wire to hardware pin p14
There is a pattern there! Many commands use one or more BASIC Stamp hardware pins as input and/or output, and the command will contain a reference to the logical pin number. The pins on the BASIC Stamp are pretty much interchangeable, and any pin can be used with just about any command. That flexibility is one of the great strengths of the Stamp. You have to understand, and make sure the pin the hardware is connected to is the same pin logically referenced by the command. Or else, nada, nothing!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
·· I'm headed down to NASA Marshall Space Flight Center and Kennedy Space Flight Center for several days; unfortunately, I won't have the MAWD-BOE with me. The ARLISS Team New Hampshire rocketeers will be checking in and logging in with questions, etc., and I will too.
Sylvie,
Here's a link to a feature story about the ARLISS team·that appeared this morning·in the Concord (NH) Monitor (front page news!) It's documentation that·you could use to·support your application for promotion if you'd like:
http://concordmonitor.com/apps/pbcs.dll/article?AID=/20090615/FRONTPAGE/906150304
Thanks for the helpful information and photos about the wiring. I thought I had it wired wrong and I was skeptical about putting the resistor on the brown wire. But I saw that you had use two resistors and that you had the red wire connected, so I did. I'm eager to get the MAWD wired to the BOE so that it WORKS when I get back!
Mark
·
I'm looking forward to hearing about your progress when you get back. I put a little time yesterday into running it through PLX-DAQ, and have a working (though still crude) version of that. The MAWD is attached to an XBee, sends the altitude data to another XBee on that 2px Super Carrier board, which sends the data through PLX-DAQ to an Excel sheet for real-time graphing of the reported altitudes. It seems to work fairly well, as long as the altitude is significantly over that 160 foot "trigger" level. If it just hangs around that level, weird things happen. I think that's a matter of how the MAWD's firmware works, though.
If I can find the time, I'll mount this MAWD in a payload bay with the XBee, and fly this thing in a couple of weeks.
Pavel and the MadWest team should be having a blast at the Paris Air Show anyway. One of these years I'm going to have to get to it:
http://dpi.wi.gov/seachange/sea0823_4.html
·· Thanks for sending the nice article about the Mad-West TARC team. I wish we were off to the Paris show with them! What a great group of young rocket scientists, and mentors. Pavel's a real charcter, isn't he? He said you can still see·his burned-off area from space with Google Earth!·You should have seen him at TARC nationals, pacing like a nervous hen, watching the last scores go up, then finding out they·had won the national championship. I'm sure you had your hand in the pie somewhere too, so you share their victory. I think in a way, we all do. These projects and successes certainly aren't one-man (or woman) productions. The MAWD-BOE-ASP certainly isn't.
It was hard to table the MAWD-BOE and pack for this morning's trip to Marshall Space Flight Center. I almost included all the Parallax gear: multiple BOE's, wires, resistors, power supply, tools, etc. But looking at the itinerary it seemed like there would be·little uninterrupted time to do much more than connect the wires·to their <proper> inputs (plus,·the bell jar and vacuum pump would have been hard to pack!)
I can't wait for the school·year to end (June 29th...!) so we can immerse ourselves in the MAWD-BOE·and get it fully functional. Hard to believe that we only have five, 3-hour practice sessions scheduled before we head to Nevada in September to launch. My son and I will do most of the tinkering and troubleshooting between practices, with your and Tracy's guidance, with some of the Rocketeers popping in as the time allows. Many of them are attending 5- and 6-week long advanced study summer programs as a direct result of their involvement with these projects (and some received full scholarships to attend) so you can't fault them for not being here at every beck and call. So it goes. Welcome to the 'real' work on engineering design, and the challenges of being on a design team.
I'll check back in evening·from Huntsville; the kids should be checking in today sometime. Thanks for your patience and tutelage!
Mark
The only reason I'm at the Parallax site at all is that the University School of Milwaukee group used Stamps in one of their SLI endeavours, and those guys (Spencer Graves in particular) brought me into the fold (they took me to Vernier.com as well). What a great education those kids are getting with this stuff. Spencer Graves is the next Werner von Braun (without the bad side). Brilliant kid.
·I have a question. You were talking about a 2px Super Carrier board earlier, and I was just wondering what a 2px Super Carrier board is? Also what does it do? Is it like the Basic stamp or is it different?
Thank you all for your replies and we appreciate all of your help.
Sean from ARLISS-NH
·
·
·
·
It's two separate products. The $20 Super Carrier board is a sort of stripped-down BOE board:
http://www.parallax.com/Store/Microcontrollers/BASICStampDevelopmentBoards/tabid/137/CategoryID/12/List/0/SortField/0/catpageindex/2/Level/a/ProductID/122/Default.aspx
I have a 2px Stamp mounted on mine:
http://www.parallax.com/Store/Microcontrollers/BASICStampModules/tabid/134/CategoryID/12/List/0/SortField/0/Level/a/ProductID/392/Default.aspx
Mine has a third product on it as well, the $15 LCD appmod:
http://www.parallax.com/Store/Accessories/Displays/tabid/159/CategoryID/34/List/0/Level/a/ProductID/53/Default.aspx?SortField=ProductName%2cProductName
You might be able to make do with one of these instead of putting a much more expensive BOE into the air. It's a serial interface rather than a USB, and there are no Servo headers, but otherwise I think it's pretty much the same as the BOE. Maybe I'm missing something, though.
·
Another question, if we did do one of these instead of the BOE, would there be a lot of programming involved? Would it be easier to do this or to do the BOE?
·
Appreciate all of your help.
·
Sean from ARLISS-NH
·
I'd go with the carrier board for this type of project.
Edit: sorry to steal you thunder sylvie...
You could put a solderless breadboard onto the Carrier board instead of soldering, but as SRLM pointed out (accurately, as always), a soldered version of your hardware will hold up better to the jolting around it'll suffer through (more so on ejection charges than on launch).
If I were you I'd seriously think about going to the Super Carrier board, unless you're using the Servo connectors on the BOE. I'd rather launch a $20 part than an $80 part.
You asked about the "2px Super Carrier board", and I just wanted to add my opinion. The super carrier board would be great, but you know that it can be used either with the original BS2 that you have now, or with any one of the other 24 pin Stamp modules. The BS2px is the fastest Stamp module, but it also draws the most electrical current and I would not recommend it for this project where you want to be sure that your battery lasts through the mission. Either stick with your BS2, or if you do find you need more features and program memory, then consider the BS2pe, which is designed for low-power data logging.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
That means that the batteries should never have to supply more than about an hour's worth of power to the systems. Now, again, Tracy is the expert, and I defer to his judgment, but wouldn't even a simple 9V alkaline be more than capable of supplying that, even to a 2px?
One possible flaw in my reasoning: the rocket will sit on the ground after the flight for quite a bit longer than the flight prep and flight itself. If the datalogger needs to be manually turned off to close files properly, battery life is an issue. It does seem to me, though, that the whole thing should be programmed to close the files at the end of the flight (e.g., after 20 consecutive readings of "00000" for altitude?).
Now if they don't need the 2px's speed, this is a complete non-issue, of course. Re. the 2pe, isn't the "data-logging" advantage of that chip it's extra EEPROM? It's not much faster than the BS2, and draws five times more power (though less than a third of what the 2px draws). If they're using the USB datalogger, I don't think they need the 2pe, unless they're going to use it _instead of_ the USB datalogger.
One data logging advantage of the BS2pe comes when a program makes extensive use of the SLEEP and NAP commands to save power. The BS2pe wakes for only 0.18 milliseconds to check status, compared with 18 milliseconds for the other stamps, including the BS2. Another advantage it shares with the other BS2p Stamps is all the extra commands, scratchpad ram, and program memory. That would be a help if the rocketeers need to expand their program or add other sensors.
I do think the BS2pe would be a good alternative, to log the data in its eeprom instead of on the USB datalogger, and thus avoid certain power supply and mechanical issues.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
How would we get a BS2pe if we happened to use one? Would we have to buy it? Also you said that it logs the data into an eeprom, what is an eeprom? Is it pretty much like the memory holder?
Thank you all for your replies.
Sean from ARLISS-NH
·
·· You've asked some good questions and I see you've received some expert advice on behalf of the team. Thank you for doing your part while I'm at Kenedy Space Flight Center, and for taking a leadership role.
You may want to mention to Dr. Allen and Sylvie and SRLM and our friends that·we do have a limited amount of space on the 'Pod'. Will there be enough space for a different circuit board? What size is·the proposed new board·(you can look that up on the Parallax website)? Do we have enough funds in our budget, and ample time to re-wire the new ASP?
Sean, please e-mail your teammates and ask them for a definitive answer:·high is the rocket going? It gets really cold at 40,000 or 50,000 feet! How will that affect battery power draw, or power drain? Is there water vapor (ice crystals) 'up there' that might affect the ASP? How? Should we insulate the ASP if we launch to 50,000 feet?
Good work, young rocket scientist! Be sure to check the website (below) that I e-mailed everyone earlier today about the Florida Space Grant team's high-altitude project. Some of their engineering concerns are also our concerns. Maybe they have an answer already... or maybe not!
http://www.fsi.ucf.edu/groundstation/
Contact Mr. Eppig, project director·at
> ·reppig@mail.ucf.edu
FYI, yesterday we went right out to the space shuttle while it was on the launch pad, ready for its July 11th launch! Sean, you share this possibility. Keep working diligently, and keep asking (and answering!) the questions you pose.
From Kennedy Space Flight Center, aim high,
Mr. Kibler - Tuesday, June 23
Right now you are using the original BASIC Stamp 2, the one in the center of the bottom row in the attached picture. It is one member of a family of BASIC Stamp modules that Parallax sells. The BS2pe is in the top row. It is next to the BS2px, which has also been mentioned in this thread.
The BS2pe is a different thing from the BS2 you have now, and yes, you would have to buy it (from Parallax) out of your project budget. I hasten to add that I am not suggesting that it is something that your team needs to rush out and do. Not at all. Making any changes in a working setup is a big deal and you should weigh the pros and cons. I'm more inclined to suggest that you stick with what you've got.
Eeprom stands for "electrically eraseable programmable read only memory". A mouthful, and kind of a contradiction in terms. How can it be read only, programmable and electrically eraseable all at the same time? There is an interesting history there, but your guess is correct, it is a "memory holder". It is the type of memory that holds the program that is running on the green BS2 that you have now.
There is 2048 bytes of this EEPROM memory on the BS2. The other members of the Stamp family have larger amounts, and the BS2pe has the most, 32768 bytes. That memory can be used partly to store a program that you write in PBASIC and any left over can be used to hold data such as ASP data you collect during your launch. At it stands now, your program is storing the PBASIC program in the EEPROM on the BS2, and the ASP data on the USB datalogger memory stick.
I hope that helps.
Maybe Mr. Kibler will be in Earth orbit the next time we hear from him!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 6/24/2009 7:02:17 AM GMT
Also, are the stamps interchangeable on our Board of Education? Can the BS2 easily be removed and replaced with another stamp, such as the BS2pe or BS2px -- or would we need to order a new board?
Thanks,
Andrew
For the most part, the stamps are electrically interchangeable (identical pinouts). The exception is the BS1 (different model) and the BS2p40 (too big). You'd have to adjust your code if you change to any other model besides a BS2e.
As for being able to modify your program in time, it all depends on how much time and effort you're willing to put in, and what you want to accomplish. For the most part, you could just time critical commands as show in this thread.
As I understand it, right now the plan is for you guys to record the data on the USB datalogger, so you're not using the BS2 EEPROM at all. If you stick with the datalogger, then the additional EEPROM of the BS2pe is irrelevant, since that's not where you're putting your data. If you do decide to store the data in EEPROM, I'm sure you'll want that extra space. However, that will require writing code to put the data there rather than on the USB stick.
Now on the plus side, I think it's considerably easier to put data in EEPROM than to use the USB datalogger. Read the pages for the "Put" and "Get" commands in the help file. In addition, it's one less piece of hardware to put up in the rocket (since the EEPROM is built into the Stamp module).
You will have to figure out if the available space in EEPROM will be enough for all of the data you're gathering. That's not really an issue with the USB datalogger, as you'll surely be using a USB stick large enough to hold a LOT more data than you can collect in one flight. With a 2pe you get about 32,000 bytes of data storage area, as Tracy pointed out. Each of your data points will probably use two bytes (since one byte can only hold numbers from 0-255), which means you'll have enough to hold 16,000 data points (* someone else step in here if that doesn't seem right to you *). Let's suppose you have 5 sensors whose values you're recording, and you're taking 5 measures per second. That's 16,000/5/5 = 640 seconds' worth of data (10 minutes and 40 seconds). As you can see, it is quite possible for you to come up against the storage limits of the EEPROM. Actually it's a little worse than that - your program will be using some of that same space, so the bigger the program, the less space you have for data.
By the way, with the BS2 chip has only 2048 bytes of EEPROM, which means 1024 data points (and less, when you count the bytes used up by your program). Even if you had no program in there, that'd be 1024/5/5 = 40 seconds' worth of data, which is obviously not enough.
If you're planning on fewer measurements per second, you can stretch that data space out quite a bit, though. If you did once per second, with the BS2 that'd be enough for about 3-1/2 minutes of flight (again, assuming no program, which is not a realistic assumption) and the BS2pe would give you about 53 minutes' worth of data collection (again, assuming no program).
I'd say that you have to decide how much data you want to collect, and then determine whether or not there's enough EEPROM space on the chip you're using for those data. If not, or if it's looking "iffy", stick with the USB datalogger. You might want to do that anyway, since (if I remember correctly) your group used it successfully last year, and it's sometimes best to stick with what you know.
Just to muddy the waters a bit more, it IS possible to add external EEPROM by attaching additional chips to your board. It's really not that hard, and in the long run, that's what I intend to do when I make dataloggers for flight in rockets. The MAWD altimeter you're using stores its measurements in an external EEPROM chip (a very small one soldered onto the board itself).
Of course I could be grounded by weather, or by not having the parts I need. I haven't yet looked at the 4" boosters I have available - I lost my old reliable one to rocket-eating trees last year (along with my first altimeter, a great Missileworks RRC2 that had something like 40 flights on it). I also still have no idea if the range will be sufficient (I'm using Series 1 XBee Pros on both ends, with the little wire antennae).
What temperature would one expect at 50000 feet?
Rocketeers, I looked again at the program that Mark attached to the first post in this thread, which I guess is the final program from last year. It has only 13 bytes of program EEPROM free and 5 words of RAM. But there is a lot of extraneous stuff in there. How is it going to change for this current year, if at all? For example, is it going to have to do the robotic exploration (servos)? Is it going to have to send out messages by Morse code? Are you adding or subtracting sensors or capabilities?
As it stands, it stores data on the USB drive as often as it can get around the main program loop, which has a lot to do with all the movements, sensor reads and writes, and morse code, and I wildly guess it takes on the order of 20 seconds to get around the loop. The USB logger stores 24 bytes in each record. At 3 records per minute, it would take about 7 hours to fill 30000 bytes. That is if the data is stored as fixed field ascii text. If it is stored as binary, then there would be 7 bytes per record.
Assignment for Sean and Andrew: How long would it take to fill 30000 bytes if 7 byte records are stored at 5 second intervals?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Mr. Allen,
I think we should be able to remove a lot of code from last year's program. Since the atmospheric sampler will not have wheels, we will not be needing anything regarding movement or the servos. I believe we also made the decision that the Morse code LED (and it's programming) would probably be removed since it would use less power, and less programming space.
"Assignment for Sean and Andrew: How long would it take to fill 30000 bytes if 7 byte records are stored at 5 second intervals?"
If 7 bytes were stored every 5 seconds, it would take just under 6 hours to reach 30,000 bytes of data -- equal to 84 bytes /minute, or 5040 bytes /hour.
Andrew
I agree with Mr. Allen, and keeping what we have. The data logger collects data so we wouldn't need more EEPROM on the stamp. Also·we don't have much time on our hands with only four more meetings left.
At 30,000 feet it can get as cold as -30 degrees Celsius. I believe that batteries provide lower voltage and drain faster in the cold. Please correct me if I am wrong.
Thanks everyone for all your time and help,
Tom ARLISS-NH
In general lithium batteries have the best preformance in the cold, but with a little insulation the battery and BOE may not get that low.
It does look like you can save a lot of program space by removing the movement the the Morse code code. That would make room for code to aquire the MAWD altimeter data. It will still do temperature and humidity from the Sensirion sensor, right?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
·· Thanks for·your wonderful input, thoughtful questions... and even giving the Rocketeers assignments while I'm here at NASA!
Tracy,
Yes, we·plan on·using the dead-man pull unless a 'better' idea surfaces.·It seems like a simple, low-tech,·funtional solution. You make an excellent point about freeing up space by deleting the robot's servo motor commands and the Morse code commands. I think Thomas made that observation several days ago (good work, Tom.) No motors, no commands needed, right Rocekteers?
If we insulate the BOE we risk inadventently covering up the SHT sensor, which needs air (gas) circulation. My wife e-mailed today to say the Parallax methane sensor came in. It's modular, and it's available as an add-on if space and time (not space-time) allow.
All of you made, independently, a similar and·intersting point about switchng Stamps: it would require a major re-work that doesn's seem practical given our time and budget constraints.
Sylvie, I'm eager to hear the flight status report when you launch your 4" rocket for data acquisition this weekend. I'd like to see the raw data, the read-rate, etc.
On the ride back from Kennedy Space Flight Center to MSFC today, I worked on defining the statistical hypotheses and test(s) we'll be using to analyze the data. The research question, as of this moment, is: "Is there a difference between humidity (or methane) at ground level and 3,000 meters above ground level (AGL)?" I agree wholehearted with you that we need to decide what altitude we are launching to. It's a fundmental engineering question that needs to be resolved as we continue designing and building since·"Form follows function". And, as Thomas pointed out, it's about -30 degrees Celsius at 30,000 feet (about 10,000 meters for Anglophonic engineers.)
Andrew, I met a friend of yours here at Marshall Space Flight Center tonight...!! He gave me something very special to give to you at our next team practice. You also have 'goodies' from Kennedy SFC. I think you're discovering that it pays to be a team leader. Keep up the good work, all of you.
Thanks everyone; more upon my return tomorrow.
Aim high (*but HOW high?),
Mr. (Mark) Kibler
You said that lithium batteries perform best in the cold. Do you happen to know how long a lithium battery would last? If we used a lithium battery, would we need to·use an extra battery or do you think·one could last the whole time?
Thanks everyone for your time and help,
Sean from ARLISS-NH