@ Sylvie369, Wow! How do you find those extra hours in every day! I wish I knew how to extrapolate like that!
I'm an academic. I get credit for doing this kind of thing.
Plus I'm at the tail end of a sabbatical. Yes, that means 8 months of paid vacation, as long as I work on an academic project of some sort. Mine was to study Spanish in Andalucia, and to learn to build sensor devices. Life is sweet.
(Do well in school! It pays off!)
Incidentally, Mark, you may remember I asked if I could include some of your comments in my application for promotion. I·did get my promotion. More $$$ for Parallax parts, to fuel my learning compulsion.
===================
Re. the interpolation/extrapolation thing, it's fairly unlikely that anything weird is going to happen between data points that you've already gathered, if the fit of those points to a curve is statistically significant. It's possible for there to be "weirdness" like Tracy's little purple "unlikely interpolation" loop, but not likely, and more importantly, we can say just how unlikely (that's what inferential statistics do for us). But when you move beyond the limits of the data you've collected, it becomes very possible for the real data to not fit your extrapolation, for a variety of very clear and common reasons, including (but definitely not limited to)
- reaching the physical limits of a process, such as the "saturation" that Tracy mentioned
- reaching the logical limits of possibility, like my "90 hours in a day" example
The logical limits can often be anticipated (obviously they can in my example), but the physical limits of a process could come as a complete surprise. It's a very good thing to be aware of when you've moved from interpolation to extrapolation, and to understand that you're relying on a lot of untested assumptions at that point.
Incidentally, this is one of the many things I learned from rocketry. I used to read the little tables of the amount of weight that could be lifted safely by various sizes of motors, and looked at the recommended motors for all the little Estes rockets. I could see how they figured which motors were the right ones for which rockets. But I of course had fantasies about flying much bigger rockets, ideally one that I could ride in, and I used to figure out how many "D" motors it would take to add up to enough thrust to lift me. But of course all sorts of other things come into play when you're dealing with lots of motors, and large rockets, and I realized that you just can't divide my weight by the weight lifted by a single D motor to find out how many Ds it would take to lift me. The way we normally say this is "It just doesn't 'scale up'".
Post Edited (sylvie369) : 5/30/2010 12:59:34 AM GMT
What is "saturation"? When it reaches this point called "saturation", what happens?
Thank you all for your time and help,
Sean
You should ask Tracy. If you look above at his post with the graphs, you'll see where he raises the issue.
As I understand it (but ask Tracy!), it amounts to this: sensors react to whatever it is that they're measuring by changing in some physical way. For example, look at page 3 of this document:
It clearly explains the physical process by which a Memsic 2125 accelerometer measures acceleration. Of course it _doesn't_ explain how those four temperature sensors inside the 2125 measure temperature, but you know there must be another physical process by which that happens (I imagine it has to do with changes in resistance of a material as the material is heated or cooled).
Now, sometimes the physical process reaches some kind of limit. All of a chemical may be used up (that happens often in photography), or a temperature may reach a limit where it can't change ·a material any more. If you were measuring acceleration by measuring the displacement of a hanging weight, you might reach the point at which the weight is hanging straight out sideways, or perhaps it bumps up against the sides of your container. When the physical process a sensor uses reaches its limits, the sensor is saturated.
Dr. Allen,
It was me that posted that philosophical answer. I didn't have time to switch users since I was in science class..
Sorry for such a small post, I got to run!
P.S. Im on pg 48 of, "What is a Micro-controller". Just learning on how to turn and LED on and off through programming.
Thanks for your excellent tutorial on extrapolating and interpolating data. Thanks too, for the assignment about CO2 concentrations at various altitudes. We understand how these assignments and this knowledge relate to programming the CO2 sensor and we would like to start programming the CO2 sensor into the ASP. Does this seem like a logical next step to you?
Please understand that we are just beginning to learn PBASIC programming and that we only meet in person as a team every two weeks or so. We will be meeting this Sunday and we are eager to install the CO2 sensor on the ASP/ MAWD-BOE. Where do you suggest that we begin with programming?
Here are some points that we will need for programming the CO2 sensor:
• The range of the CO2 concentrations, since we will not be going higher then 7km, are 345-410 ppm (estimated, rounded both up and down just to be safe incase we hit higher concentrations than estimated).
• Here is what we think is a formula-- an algorithm-- for converting Milivolts to PPM for a temperature-humidity sensor. Will the one for our CO2 sensor look something like this?
It's not clear to me from your code snippet that you understand what subroutines are. My apologies if I'm misreading the code.
When there is some set of commands you want to run repeatedly in your program, it often makes sense to put them into a subroutine. That allows you to run that set of commands by just "calling" the subroutine, which you do by the name of the subroutine. It's almost as though you've added another command to the PBASIC language.
and it continues until the RETURN command. What made me suspect that you didn't understand how this works is that you have a GOSUB inside of your subroutine that is apparently meant to call that subroutine. Now, that's not unheard of - it's called "recursion", and done properly, it's a very effective way to reduce the amount of code needed to do a task. But I don't think you meant this to be a recursive subroutine, and in fact I believe that PBASIC does not support recursion (though I could definitely be wrong about that).
I think that what you meant was something more like this:
Main:
(some program code)
(more program code)
GOSUB SHT_Measure_Humidity (* Run the code in the subroutine *)
(more program code)
GOSUB SHT_Measure_Humidity (* Run the code in the subroutine again *)
(more program code)
End (* Needed to keep the program from "falling into" the subroutine at the end *)
Yup, your completely right . We were not sure what that code does, we were just trying quickly to find some code that we *thought* went into the classification of converting Millivolts into PPM. Once again we are not completely sure where to go from here into programming.
·· I think Dylan and Mike posted the subroutine to ask if it contained an algorithm. It does, doesn't it? They·determined that output voltage (mV) from the CO2 sensor needs converted to numbers (ppm) "using a formula" (a computer program that contains an algorithm.) The·subroutine they chose·is part of the program from last year's ASP (aka the MAWD-BOE.)
Clever that you picked up on recursion in the program!
"Now, that's not unheard of - it's called "recursion", and done properly, it's a very effective way to reduce the amount of code needed to do a task."
·As I recall Tracy·used recursion·to reduce the amount of program code because the BS2 was running short on memory Like me sometimes.) The BS2e that's on the way should give us more program space (yes?)
·· We've determined that there isn't enough physical space on the ASP/ BOE to plug the CO2 sensor in directly.However there are enough·input/ output "holes" to wire it in. We will be mounting (screwing) the CO2 sensor directly·to the wooden plate on the ASP.
Please download and look at the photo of the ASP's BOE that Andrew uploaded to the forum (on page 1?) Then look at the CO2 sensor's schematic (which you downloaded and put in your team binder.)
Tonight, use your schematic to determine:
1) Which "holes" (P4?, P11? etc.) are available on the ASP/ BOE for us to wire the CO2 sensor to? Be specific. Make a diagram on graph paper to help you figure out which inputs/outputs are being used, and which are available.
Recall that Dylan reports that:
* Vss is for ground (GND)
* Vdd is for 5+ volt output
* One of the CO2 sensor's pins is used to activate an alarm (ALM.) Where will that wire plug into the BOE?
* Which pin on the CO2 sensor will the other wire come from? What is it for? Where will it plug in on the BOE?
Is Dylan correct...? Double check before·we "fry" our one and only CO2 sensor!
Rocketeers, you will physically mount the CO2 sensor on the ASP at this Sunday's practice. I would also like you have enough knowledge about PBASIC programming to start writing a rudimentary program for the CO2 sensor. Some could mount the sensor while others write program code. It's for this reason that you will need to know the "pin outs" (what "holes" on the BOE·will the wires from the CO2 sensor's pins will·go to.) Look at the program that Andrew uploaded. From that you should be able to·determine which inputs are used and which are available. Sylvie and Dr. Allen will guide you in writing and fine-tuning the program. But you have to tell them what you want it to do! How do you want the data to·appear? Where do you want it to go, to be stored? Don't you want to correlate it with altitude,humidity, temperature,·and flight time like we did last year...?
TRACY and PAUL, given that the sensor won't be plugged into the breadboard and that it will be mounted directly to the ASP, do you think we should solder wires to the pins on the sensor when it arrives? Or should we wait·until the·program·is started? What direction do you suggest we go in at this·point? Are we on the right track?
But if we put the sensor so that the pins are connected to the pin outs, wouldn't that pose a problem? I believe that the o/i pins (p0, p1, p2 etc..) are directly wired through the circuit board into the stamps pin inputs? And if we don't have enough space, how would be connect it to the from the pin i/o like p4, to a different stamp. We could not wire it to the flash drive because we need a micro controller to use the formula to convert it from Millivolts to PPM on the fly. Unless we recorded the raw numbers to the flash drive then published a formula on another flash drive so we could convert it. Hmm...
·· Check the photo of the ASP and look for the (two? three?) wires coming from, and going to,·the MAWD (MAWD = 'altimeter with deployment' feature.)·The MAWD is·mounted separately from the BOE/ breadboard yet it records altitude to the DataLogger (flash drive) perfectly. The signal (output) from the MAWD is routed through the BOE's microprocessor and converted into data--- the·ASP's altitude.
Here's an excellent opportunity to work with ANDREW. Please e-mail him and post to the forum so·that he can·explain how the MAWD and the BOE are integrated, and so that newer teammates can understand·how it all fits together. The CO2 sensor·will be mounted separately, similar to the MAWD. Or can it be? Are there enough input/ output·"holes" for the wires coming from the CO2 sensor to make it work?
May I ask, where is the MAWD located? Im looking at the first photo on the first post of this thread and cannot seem to find it...
Dylan Landry
The MAWD, as I recall, is located directly under or beside the Parallax circuit board on the ASP. It is directly integrated with the circuit board. I believe the photo I originally posted was the Parallax board detached from the entire ASP unit. I'll see if I can find the original posts detailing about how the MAWD is integrated with the circuit board -- or you can take a look at the assembled ASP itself to visually see how it is integrated.
Post Edited (Andrew (ARLISS)) : 6/2/2010 12:14:10 AM GMT
Got it! Here's a photo of the ASP in its early stages with the MAWD mounted above the circuit board. However, it does not appear that they are connected yet -- but you should still get the bigger idea of how it works. The link below is to a previous thread, and on page 6 and 7 there is a large amount of information about how the MAWD and BOE were integrated. This will be worth reading now as it will make more sense to you when we discuss this later.
Mark in NH said...
ROCKETEERS,
We've determined that there isn't enough physical space on the ASP/ BOE to plug the CO2 sensor in directly.However there are enough input/ output "holes" to wire it in. We will be mounting (screwing) the CO2 sensor directly to the wooden plate on the ASP. This sounds like what I had originally thought. I think this should be an adequate solution, but does anyone disagree?
Tonight, use your schematic to determine:
1) Which "holes" (P4?, P11? etc.) are available on the ASP/ BOE for us to wire the CO2 sensor to? Be specific. Make a diagram on graph paper to help you figure out which inputs/outputs are being used, and which are available.
There is a comment in "MAWDBOE_July12ta-ckV2.bs2" that states:
' note Stamp [b]p3, p4, and p6[/b] are unused
This means we have THREE unused IO slots available. Keep this in mind and use them wisely. Can someone also check *physically* that p3, p4, and p6 are unused?
Recall that Dylan reports that:
* Vss is for ground (GND) - Correct.
* Vdd is for 5+ volt output - Correct.
* One of the CO2 sensor's pins is used to activate an alarm (ALM.) - Doesn't the *module* have an alarm? My understanding is that the CO2 sensor itself just outputs data. Someone feel free to crosscheck this.
* Which pin on the CO2 sensor will the other wire come from? What is it for? Where will it plug in on the BOE? - Someone should crosscheck the schematics, but I believe there are 3 necessary connections for the sensor itself (power, ground, input/output). I believe this is different if we use the full sensor module, though.
Is Dylan correct...? Double check before we "fry" our one and only CO2 sensor!
Mark
Sources:
BOErevC.pdf - attached
Take a look at the link below if you also look at the BOE schematics. It is a simple guide of the common symbols you might encounter.
Ah, I think I see. I hadn't looked carefully at your code in the earlier projects, so sorry if I missed something already decided upon and working.
Mark asked if I thought the wires should be soldered to the CO2 sensor pins. Your choice is really between that, and using female prototyping wires, which simply press onto the sensor pins. You'll be experiencing some g-forces, as you've learned in your earlier flights. However, if the heavy parts (sensor, BoE) are solidly mounted, there's very little chance that the g-forces are going to disolodge a light little wire. You might put a wrap of electrical tape around them, but I doubt that you'll need to solder. Of course the only way to find out* is to fly and hope you don't fail, so you should take that into account. You're already doing essentially the same thing by trusting all of those wires just pressed into your protoboard (oh, wait, I see you hot-glued them. You might consider that here as well).
* Well, I suppose you could rig some kind of way of ground testing it, which would be pretty interesting in itself.
Dylan wrote
"We could not wire it to the flash drive because we need a micro controller to use the formula to convert it from Millivolts to PPM on the fly. Unless we recorded the raw numbers to the flash drive then published a formula on another flash drive so we could convert it. Hmm..."
That's not that bad an idea. If you have the program space to do the conversion on-board, that's fine, but it doesn't have to be done that way. There's nothing at all wrong with recording raw values and doing the conversions later on the ground. That's how we did it in the near space balloon flight I worked on a year ago, and it's how I avoid having to fly computers at all (so far) in·my rocket telemetry flights. If the conversions start taxing your BoE's program space you should consider just recording raw data, and doing the conversions later, as you suggested.
sylvie369 said...
Ah, I think I see. I hadn't looked carefully at your code in the earlier projects, so sorry if I missed something already decided upon and working.
Mark asked if I thought the wires should be soldered to the CO2 sensor pins. Your choice is really between that, and using female prototyping wires, which simply press onto the sensor pins. You'll be experiencing some g-forces, as you've learned in your earlier flights. However, if the heavy parts (sensor, BoE) are solidly mounted, there's very little chance that the g-forces are going to disolodge a light little wire. You might put a wrap of electrical tape around them, but I doubt that you'll need to solder. Of course the only way to find out* is to fly and hope you don't fail, so you should take that into account. You're already doing essentially the same thing by trusting all of those wires just pressed into your protoboard (oh, wait, I see you hot-glued them. You might consider that here as well).
* Well, I suppose you could rig some kind of way of ground testing it, which would be pretty interesting in itself.
Dylan wrote
"We could not wire it to the flash drive because we need a micro controller to use the formula to convert it from Millivolts to PPM on the fly. Unless we recorded the raw numbers to the flash drive then published a formula on another flash drive so we could convert it. Hmm..."
That's not that bad an idea. If you have the program space to do the conversion on-board, that's fine, but it doesn't have to be done that way. There's nothing at all wrong with recording raw values and doing the conversions later on the ground. That's how we did it in the near space balloon flight I worked on a year ago, and it's how I avoid having to fly computers at all (so far) in my rocket telemetry flights. If the conversions start taxing your BoE's program space you should consider just recording raw data, and doing the conversions later, as you suggested.
Sylvie,
Thank you for the thoughtful suggestions! Regarding the connection of the circuit board and CO2 sensor, are you referring to a wire such as the one listed below? This seems like a feasible, non-permanent solution to connecting the two together. However, what downsides are there to just soldering it? Last year's launch at ARLISS was flawless, and I don't recall any wiring related issues. However, if I remember correctly, either a wiring or a loose switch disabled a PASCO PasPort system in our NASA Student Launch Initiative rocket. I believe we narrowed down the cause to the initial forces at launch, which pushed a selector switch to the 'off' position.
If we mount the CO2 sensor so it does not connect with the stamp and only the MAWD, I believe that the only way we could collect data is in the raw form (in Millivolts).. If it is not connected to the stamp which contains the micro-controller, how will we be able to upload a formula to convert the data?
For the inputs/outputs that are available, does p13 have a wire already attaching it to something? I couldn't really tell from looking at the diagram if it was a wire or if the wire was connecting into it.
For the inputs/outputs that are available, does p13 have a wire already attaching it to something? I couldn't really tell from looking at the diagram if it was a wire or if the wire was connecting into it.
Dylan Landry said...
Dear Andrew, Dr. Allen and Sylvie,
If we mount the CO2 sensor so it does not connect with the stamp and only the MAWD, I believe that the only way we could collect data is in the raw form (in Millivolts).. If it is not connected to the stamp which contains the micro-controller, how will we be able to upload a formula to convert the data?
Dylan Landry
Dylan and Rocketeers,
·· I respectfully disagree that "the only way we could collect [noparse][[/noparse]CO2] data is in the raw form..." Last year's ASP recorded temperature, humidity, altitude AND flight time all in the "correct" units (not as raw data.) Recording CO2 concentration as raw data would still require·us to·calculate and·recheck our math, on the ground right·after the flight. Remember that this takes time and we will be many miles out in the 'playa' (desert.) After the ASP-2 lands we would have to convert raw data to CO2·concentration (using·an algorithm, etc., etc.)
I would rather that the·ASP records actual CO2 concentration. That way we can·tell instantly after landing whether·it measured and·recorded·"good" data (or not) so·that we can make a quick decision·about whether to launch again (or not.) Our·launch window (the time we have available to launch) is the desert is really narrow and·we·may need to make a quick·decision to launch again (depending on wind, time of day, etc.) I'd rather·that we not have to scamper back to our project area and·check and re-check calculations...·then have the launch window close.
For several reasons I would like to work with Dr. Allen and Sylvie to·program the CO2 sensor so that it reads out CO2 concentration in ppm along with altitude, flight time, temperature and humidity. Just my thoughts. Sylvie and Dr. Allen outrank me, and·you Rocketeers outnumber me...!
Thank you for the explanation on how we would go about it. I just have one more misunderstanding.. If we would be wiring to the P#s, how would we get it not to go to the stamp? If i am wrong, could we still get the sensor to connect through whatever pin o/i, get the stamp to record the data, without taking up space on the BS2? I am confused in how to get it to connect to the MAWD but go though the
Pin o/i's...
Thank you for the explanation on how we would go about it. I just have one more misunderstanding.. If we would be wiring to the P#s, how would we get it not to go to the stamp? If i am wrong, could we still get the sensor to connect through whatever pin o/i, get the stamp to record the data, without taking up space on the BS2? I am confused in how to get it to connect to the MAWD but go though the
Pin o/i's...
Dylan Landry
Dylan,
I understand exactly what you are saying. All the data does in fact pass through the BS2 stamp at one point or another. However, data isn't stored on the BS2. Instead, it is passed from the sensor, to the BS2, and then to the datalogger, which records it for later retrieval on a USB flash drive. The BS2 (and BS2e) memory space is simply too small to record the thousands of lines of data that we anticipate the ASP to record. Once you get a better understanding of the PBASIC programming language, you should be able to understand (a little) how the program works simply by looking at it. I believe you already have, but if you haven't, please download our program and take a look through it to see if any of it seems familiar with your recent reading of the book "What's a Microcontroller?".
I hope this makes more sense,
Andrew
Post Edited (Andrew (ARLISS)) : 6/2/2010 1:54:53 AM GMT
Justin Abbott said...
For the inputs/outputs that are available, does p13 have a wire already attaching it to something? I couldn't really tell from looking at the diagram if it was a wire or if the wire was connecting into it.Justi
Justin, Mike, and Dylan,
··· Look at the ASP tomorrow and see which inputs and outputs are available. Then post this information to the forum (P4?, P7?, Vss? Vdd? how many of each?, etc.)
Also, look at the picture of the ASP that Andrew just posted to the forum. Directly to the right of the red and white word "OFF"·is the·MAWD, just·above the BOE. Check tomorrow to see how it's integrated into the BOE. It's not a Parallax part but, like other electronics, it outputs voltage. Last year Sylvie and Dr. Allen figured out how to convert its electric signal/ output into altitude data. Pretty clever, those guys, huh?! Some day you may become as clever as they are. Learn today while you have great teachers!
I understand exactly what you are saying. All the data does in fact pass through the BS2 stamp at one point or another. However, data isn't stored on the BS2. Instead, it is passed from the sensor, to the BS2, and then to the datalogger, which records it for later retrieval on a USB flash drive. The BS2 (and BS2e) memory space is simply too small to record the thousands of lines of data that we anticipate the ASP to record. Once you get a better understanding of the PBASIC programming language, you should be able to understand (a little) how the program works simply by looking at it. I believe you already have, but if you haven't, please download our program and take a look through it to see if any of it seems familiar with your recent reading of the book "What's a Microcontroller?".
I hope this makes more sense,
Andrew
Andrew,
· So do you think the BS2e stamp will have enough memory for the CO2 sensor program and all the other programs...? I just checked UPS and it arrives tomorrow!
Do you think we can replace the BS2 with the BS2e without having to write a completely new program? At the very least you will have to change "BS2" to "BS2e" at the top of the program so the program recognizes the new stamp.·Yes.
Finally,·we need to find a·sample/ prototype CO2 sensor program·right away.
If you don't mind me adding (although i might be wrong), the only thing that is changing is the space. The pins aren't changing, the programming space, the datalogger path, nothing. The only thing you would have to change is click a different BS2 icon at the top of the PBASIC stamp editor.. Remember, i could be wrong.
Thank you for the thoughtful suggestions! Regarding the connection of the circuit board and CO2 sensor, are you referring to a wire such as the one listed below? This seems like a feasible, non-permanent solution to connecting the two together. However, what downsides are there to just soldering it? Last year's launch at ARLISS was flawless, and I don't recall any wiring related issues. However, if I remember correctly, either a wiring or a loose switch disabled a PASCO PasPort system in our NASA Student Launch Initiative rocket. I believe we narrowed down the cause to the initial forces at launch, which pushed a selector switch to the 'off' position.
The only downside to soldering is that it's permanent. If that doesn't bother you, then solder away. It's the most secure attachment.
Generally we do not put toggle switches into rockets because of the risk of acceleration moving the toggle. It helps to orient them so that the toggle moves at right angle the main forces (up and down).
Comments
Plus I'm at the tail end of a sabbatical. Yes, that means 8 months of paid vacation, as long as I work on an academic project of some sort. Mine was to study Spanish in Andalucia, and to learn to build sensor devices. Life is sweet.
(Do well in school! It pays off!)
Incidentally, Mark, you may remember I asked if I could include some of your comments in my application for promotion. I·did get my promotion. More $$$ for Parallax parts, to fuel my learning compulsion.
===================
Re. the interpolation/extrapolation thing, it's fairly unlikely that anything weird is going to happen between data points that you've already gathered, if the fit of those points to a curve is statistically significant. It's possible for there to be "weirdness" like Tracy's little purple "unlikely interpolation" loop, but not likely, and more importantly, we can say just how unlikely (that's what inferential statistics do for us). But when you move beyond the limits of the data you've collected, it becomes very possible for the real data to not fit your extrapolation, for a variety of very clear and common reasons, including (but definitely not limited to)
- reaching the physical limits of a process, such as the "saturation" that Tracy mentioned
- reaching the logical limits of possibility, like my "90 hours in a day" example
The logical limits can often be anticipated (obviously they can in my example), but the physical limits of a process could come as a complete surprise. It's a very good thing to be aware of when you've moved from interpolation to extrapolation, and to understand that you're relying on a lot of untested assumptions at that point.
Incidentally, this is one of the many things I learned from rocketry. I used to read the little tables of the amount of weight that could be lifted safely by various sizes of motors, and looked at the recommended motors for all the little Estes rockets. I could see how they figured which motors were the right ones for which rockets. But I of course had fantasies about flying much bigger rockets, ideally one that I could ride in, and I used to figure out how many "D" motors it would take to add up to enough thrust to lift me. But of course all sorts of other things come into play when you're dealing with lots of motors, and large rockets, and I realized that you just can't divide my weight by the weight lifted by a single D motor to find out how many Ds it would take to lift me. The way we normally say this is "It just doesn't 'scale up'".
Post Edited (sylvie369) : 5/30/2010 12:59:34 AM GMT
What is "saturation"? When it reaches this point called "saturation", what happens?
Thank you all for your time and help,
Sean
As I understand it (but ask Tracy!), it amounts to this: sensors react to whatever it is that they're measuring by changing in some physical way. For example, look at page 3 of this document:
http://www.parallax.com/Portals/0/Downloads/docs/prod/compshop/SICMemsicTut.pdf
It clearly explains the physical process by which a Memsic 2125 accelerometer measures acceleration. Of course it _doesn't_ explain how those four temperature sensors inside the 2125 measure temperature, but you know there must be another physical process by which that happens (I imagine it has to do with changes in resistance of a material as the material is heated or cooled).
Now, sometimes the physical process reaches some kind of limit. All of a chemical may be used up (that happens often in photography), or a temperature may reach a limit where it can't change ·a material any more. If you were measuring acceleration by measuring the displacement of a hanging weight, you might reach the point at which the weight is hanging straight out sideways, or perhaps it bumps up against the sides of your container. When the physical process a sensor uses reaches its limits, the sensor is saturated.
It was me that posted that philosophical answer. I didn't have time to switch users since I was in science class..
Sorry for such a small post, I got to run!
P.S. Im on pg 48 of, "What is a Micro-controller". Just learning on how to turn and LED on and off through programming.
Dylan Landry
Thanks for your excellent tutorial on extrapolating and interpolating data. Thanks too, for the assignment about CO2 concentrations at various altitudes. We understand how these assignments and this knowledge relate to programming the CO2 sensor and we would like to start programming the CO2 sensor into the ASP. Does this seem like a logical next step to you?
Please understand that we are just beginning to learn PBASIC programming and that we only meet in person as a team every two weeks or so. We will be meeting this Sunday and we are eager to install the CO2 sensor on the ASP/ MAWD-BOE. Where do you suggest that we begin with programming?
Here are some points that we will need for programming the CO2 sensor:
• The range of the CO2 concentrations, since we will not be going higher then 7km, are 345-410 ppm (estimated, rounded both up and down just to be safe incase we hit higher concentrations than estimated).
• Here is what we think is a formula-- an algorithm-- for converting Milivolts to PPM for a temperature-humidity sensor. Will the one for our CO2 sensor look something like this?
measure humidity
SHT_Measure_Humidity:
ioByte = ShtHumi ' humidity command
GOSUB SHT_measure ' send command
rh = (soSHT ** 26542)
rh = rh - ((soSHT ** 3468) * (soSHT ** 3468) + 50 / 100)
rh = rh - 40
rh = ((degC + 250 / 10 - 50) * (soSHT ** 524 + 1) + (rh * 10)) + 5 / 10
RETURN
We believe we should start learning *how* to program and so we would like to get started with this.
The Rocketeers,
Dylan Landry and Mike Prindiville
When there is some set of commands you want to run repeatedly in your program, it often makes sense to put them into a subroutine. That allows you to run that set of commands by just "calling" the subroutine, which you do by the name of the subroutine. It's almost as though you've added another command to the PBASIC language.
You have this:
·The subroutine is declared in the line
SHT_Measure_Humidity:
and it continues until the RETURN command. What made me suspect that you didn't understand how this works is that you have a GOSUB inside of your subroutine that is apparently meant to call that subroutine. Now, that's not unheard of - it's called "recursion", and done properly, it's a very effective way to reduce the amount of code needed to do a task. But I don't think you meant this to be a recursive subroutine, and in fact I believe that PBASIC does not support recursion (though I could definitely be wrong about that).
I think that what you meant was something more like this:
(I'm not sure why the editor put those ugly lines in the middle of the code here, but you can just ignore them)
Yup, your completely right
Dylan Landry
·· I think Dylan and Mike posted the subroutine to ask if it contained an algorithm. It does, doesn't it? They·determined that output voltage (mV) from the CO2 sensor needs converted to numbers (ppm) "using a formula" (a computer program that contains an algorithm.) The·subroutine they chose·is part of the program from last year's ASP (aka the MAWD-BOE.)
Clever that you picked up on recursion in the program!
"Now, that's not unheard of - it's called "recursion", and done properly, it's a very effective way to reduce the amount of code needed to do a task."
·As I recall Tracy·used recursion·to reduce the amount of program code because the BS2 was running short on memory Like me sometimes.) The BS2e that's on the way should give us more program space (yes?)
·· We've determined that there isn't enough physical space on the ASP/ BOE to plug the CO2 sensor in directly.However there are enough·input/ output "holes" to wire it in. We will be mounting (screwing) the CO2 sensor directly·to the wooden plate on the ASP.
Please download and look at the photo of the ASP's BOE that Andrew uploaded to the forum (on page 1?) Then look at the CO2 sensor's schematic (which you downloaded and put in your team binder.)
Tonight, use your schematic to determine:
1) Which "holes" (P4?, P11? etc.) are available on the ASP/ BOE for us to wire the CO2 sensor to? Be specific. Make a diagram on graph paper to help you figure out which inputs/outputs are being used, and which are available.
Recall that Dylan reports that:
* Vss is for ground (GND)
* Vdd is for 5+ volt output
* One of the CO2 sensor's pins is used to activate an alarm (ALM.) Where will that wire plug into the BOE?
* Which pin on the CO2 sensor will the other wire come from? What is it for? Where will it plug in on the BOE?
Is Dylan correct...? Double check before·we "fry" our one and only CO2 sensor!
Rocketeers, you will physically mount the CO2 sensor on the ASP at this Sunday's practice. I would also like you have enough knowledge about PBASIC programming to start writing a rudimentary program for the CO2 sensor. Some could mount the sensor while others write program code. It's for this reason that you will need to know the "pin outs" (what "holes" on the BOE·will the wires from the CO2 sensor's pins will·go to.) Look at the program that Andrew uploaded. From that you should be able to·determine which inputs are used and which are available. Sylvie and Dr. Allen will guide you in writing and fine-tuning the program. But you have to tell them what you want it to do! How do you want the data to·appear? Where do you want it to go, to be stored? Don't you want to correlate it with altitude,humidity, temperature,·and flight time like we did last year...?
TRACY and PAUL, given that the sensor won't be plugged into the breadboard and that it will be mounted directly to the ASP, do you think we should solder wires to the pins on the sensor when it arrives? Or should we wait·until the·program·is started? What direction do you suggest we go in at this·point? Are we on the right track?
Mark
But if we put the sensor so that the pins are connected to the pin outs, wouldn't that pose a problem? I believe that the o/i pins (p0, p1, p2 etc..) are directly wired through the circuit board into the stamps pin inputs? And if we don't have enough space, how would be connect it to the from the pin i/o like p4, to a different stamp. We could not wire it to the flash drive because we need a micro controller to use the formula to convert it from Millivolts to PPM on the fly. Unless we recorded the raw numbers to the flash drive then published a formula on another flash drive so we could convert it. Hmm...
Dylan Landry
·· Check the photo of the ASP and look for the (two? three?) wires coming from, and going to,·the MAWD (MAWD = 'altimeter with deployment' feature.)·The MAWD is·mounted separately from the BOE/ breadboard yet it records altitude to the DataLogger (flash drive) perfectly. The signal (output) from the MAWD is routed through the BOE's microprocessor and converted into data--- the·ASP's altitude.
Here's an excellent opportunity to work with ANDREW. Please e-mail him and post to the forum so·that he can·explain how the MAWD and the BOE are integrated, and so that newer teammates can understand·how it all fits together. The CO2 sensor·will be mounted separately, similar to the MAWD. Or can it be? Are there enough input/ output·"holes" for the wires coming from the CO2 sensor to make it work?
May I ask, where is the MAWD located? Im looking at the first photo on the first post of this thread and cannot seem to find it...
Dylan Landry
Thanks,
Mike
The MAWD, as I recall, is located directly under or beside the Parallax circuit board on the ASP. It is directly integrated with the circuit board. I believe the photo I originally posted was the Parallax board detached from the entire ASP unit. I'll see if I can find the original posts detailing about how the MAWD is integrated with the circuit board -- or you can take a look at the assembled ASP itself to visually see how it is integrated.
Post Edited (Andrew (ARLISS)) : 6/2/2010 12:14:10 AM GMT
Got it! Here's a photo of the ASP in its early stages with the MAWD mounted above the circuit board. However, it does not appear that they are connected yet -- but you should still get the bigger idea of how it works. The link below is to a previous thread, and on page 6 and 7 there is a large amount of information about how the MAWD and BOE were integrated. This will be worth reading now as it will make more sense to you when we discuss this later.
Thanks,
Andrew
Link: http://forums.parallax.com/forums/default.aspx?f=6&p=7&m=358371
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Learn to obey before you command."
-Solon
Sources:
BOErevC.pdf - attached
Take a look at the link below if you also look at the BOE schematics. It is a simple guide of the common symbols you might encounter.
http://library.thinkquest.org/10784/circuit_symbols.html
Post Edited (Andrew (ARLISS)) : 6/2/2010 12:55:23 AM GMT
Mark asked if I thought the wires should be soldered to the CO2 sensor pins. Your choice is really between that, and using female prototyping wires, which simply press onto the sensor pins. You'll be experiencing some g-forces, as you've learned in your earlier flights. However, if the heavy parts (sensor, BoE) are solidly mounted, there's very little chance that the g-forces are going to disolodge a light little wire. You might put a wrap of electrical tape around them, but I doubt that you'll need to solder. Of course the only way to find out* is to fly and hope you don't fail, so you should take that into account. You're already doing essentially the same thing by trusting all of those wires just pressed into your protoboard (oh, wait, I see you hot-glued them. You might consider that here as well).
* Well, I suppose you could rig some kind of way of ground testing it, which would be pretty interesting in itself.
Dylan wrote
"We could not wire it to the flash drive because we need a micro controller to use the formula to convert it from Millivolts to PPM on the fly. Unless we recorded the raw numbers to the flash drive then published a formula on another flash drive so we could convert it. Hmm..."
That's not that bad an idea. If you have the program space to do the conversion on-board, that's fine, but it doesn't have to be done that way. There's nothing at all wrong with recording raw values and doing the conversions later on the ground. That's how we did it in the near space balloon flight I worked on a year ago, and it's how I avoid having to fly computers at all (so far) in·my rocket telemetry flights. If the conversions start taxing your BoE's program space you should consider just recording raw data, and doing the conversions later, as you suggested.
Sylvie,
Thank you for the thoughtful suggestions! Regarding the connection of the circuit board and CO2 sensor, are you referring to a wire such as the one listed below? This seems like a feasible, non-permanent solution to connecting the two together. However, what downsides are there to just soldering it? Last year's launch at ARLISS was flawless, and I don't recall any wiring related issues. However, if I remember correctly, either a wiring or a loose switch disabled a PASCO PasPort system in our NASA Student Launch Initiative rocket. I believe we narrowed down the cause to the initial forces at launch, which pushed a selector switch to the 'off' position.
http://www.sparkfun.com/commerce/product_info.php?products_id=8430
Thanks,
Andrew
If we mount the CO2 sensor so it does not connect with the stamp and only the MAWD, I believe that the only way we could collect data is in the raw form (in Millivolts).. If it is not connected to the stamp which contains the micro-controller, how will we be able to upload a formula to convert the data?
Dylan Landry
·· I respectfully disagree that "the only way we could collect [noparse][[/noparse]CO2] data is in the raw form..." Last year's ASP recorded temperature, humidity, altitude AND flight time all in the "correct" units (not as raw data.) Recording CO2 concentration as raw data would still require·us to·calculate and·recheck our math, on the ground right·after the flight. Remember that this takes time and we will be many miles out in the 'playa' (desert.) After the ASP-2 lands we would have to convert raw data to CO2·concentration (using·an algorithm, etc., etc.)
I would rather that the·ASP records actual CO2 concentration. That way we can·tell instantly after landing whether·it measured and·recorded·"good" data (or not) so·that we can make a quick decision·about whether to launch again (or not.) Our·launch window (the time we have available to launch) is the desert is really narrow and·we·may need to make a quick·decision to launch again (depending on wind, time of day, etc.) I'd rather·that we not have to scamper back to our project area and·check and re-check calculations...·then have the launch window close.
For several reasons I would like to work with Dr. Allen and Sylvie to·program the CO2 sensor so that it reads out CO2 concentration in ppm along with altitude, flight time, temperature and humidity. Just my thoughts. Sylvie and Dr. Allen outrank me, and·you Rocketeers outnumber me...!
Mr. Kibler
Thank you for the explanation on how we would go about it. I just have one more misunderstanding.. If we would be wiring to the P#s, how would we get it not to go to the stamp? If i am wrong, could we still get the sensor to connect through whatever pin o/i, get the stamp to record the data, without taking up space on the BS2? I am confused in how to get it to connect to the MAWD but go though the
Pin o/i's...
Dylan Landry
Dylan,
I understand exactly what you are saying. All the data does in fact pass through the BS2 stamp at one point or another. However, data isn't stored on the BS2. Instead, it is passed from the sensor, to the BS2, and then to the datalogger, which records it for later retrieval on a USB flash drive. The BS2 (and BS2e) memory space is simply too small to record the thousands of lines of data that we anticipate the ASP to record. Once you get a better understanding of the PBASIC programming language, you should be able to understand (a little) how the program works simply by looking at it. I believe you already have, but if you haven't, please download our program and take a look through it to see if any of it seems familiar with your recent reading of the book "What's a Microcontroller?".
I hope this makes more sense,
Andrew
Post Edited (Andrew (ARLISS)) : 6/2/2010 1:54:53 AM GMT
··· Look at the ASP tomorrow and see which inputs and outputs are available. Then post this information to the forum (P4?, P7?, Vss? Vdd? how many of each?, etc.)
Also, look at the picture of the ASP that Andrew just posted to the forum. Directly to the right of the red and white word "OFF"·is the·MAWD, just·above the BOE. Check tomorrow to see how it's integrated into the BOE. It's not a Parallax part but, like other electronics, it outputs voltage. Last year Sylvie and Dr. Allen figured out how to convert its electric signal/ output into altitude data. Pretty clever, those guys, huh?! Some day you may become as clever as they are. Learn today while you have great teachers!
Thank you very much for the explanation! I wasn't understanding it at all. Thanks to you too Mr. Kibler along with Sylvie!
Dylan Landry
· So do you think the BS2e stamp will have enough memory for the CO2 sensor program and all the other programs...? I just checked UPS and it arrives tomorrow!
Do you think we can replace the BS2 with the BS2e without having to write a completely new program? At the very least you will have to change "BS2" to "BS2e" at the top of the program so the program recognizes the new stamp.·Yes.
Finally,·we need to find a·sample/ prototype CO2 sensor program·right away.
Keep up the good dialogue,
Mr. Kibler
If you don't mind me adding (although i might be wrong), the only thing that is changing is the space. The pins aren't changing, the programming space, the datalogger path, nothing. The only thing you would have to change is click a different BS2 icon at the top of the PBASIC stamp editor.. Remember, i could be wrong.
Dylan Landry
The only downside to soldering is that it's permanent. If that doesn't bother you, then solder away. It's the most secure attachment.
Generally we do not put toggle switches into rockets because of the risk of acceleration moving the toggle. It helps to orient them so that the toggle moves at right angle the main forces (up and down).