The reason why it resets is because the program for that specific part is designated as a variable size to contain a certain amount of numbers, this one in particular is a byte. We could easily upgrade this to a WORD and not have to worry about it again, or some other more specific size to still be able to be free up on space on the stamp.
Mark in NH said...
OK, here's the graph of the CO2 data as an Excel file again (I hope.) The ASP-BOE ran for over an hour until after midnight and the data looks 'OK'. But it needs some critical examinstion to be sure we're measuring what we think we are... CO2.
Two things:
1) I agree that we may want better resolution in the CO2 data. There seems to be "a lot" of variation (200+ units, whatever the units are.)
2) The sample number resets to 0 every time it reaches 255 (a variable of 256, 515, 1024, etc.) Hmmm...
Yawn,
Mr. Kibler
Mr. Kibler,
Thanks for re-uploading the graph, it worked this time. Although we aren't quite there yet, everything looks very promising! As for your first point, I understand what you are saying but I am not sure how we would fix or compensate for it. As for your second point, I am guessing that this would be an issue with the variable size, as Dylan suggested in the post above mine. However, I am not entirely certain.
Dylan Landry said...
The reason why it resets is because the program for that specific part is designated as a variable size to contain a certain amount of numbers, this one in particular is a byte. We could easily upgrade this to a WORD and not have to worry about it again, or some other more specific size to still be able to be free up on space on the stamp.
How high would it count before resetting if it were a WORD-sized variable?
If you needed to count higher than that, what might you add to the program?
Hint: it'd be quite easy, assuming you're not already out of variable space.
Dylan Landry said... "The reason why it resets is because the program for that specific part is designated as a variable size to contain a certain amount of numbers, this one in particular is a byte. We could easily upgrade this to a WORD and not have to worry about it again, or some other more specific size to still be able to be free up on space on the stamp"
Dylan,
This is insightful and it sounds like you're learning some things! Check my post to Dr. Allen and Sylvie above though, and you'll notice that we're out of "Word" definition space (e.g. when Chris and I changed "mVolts0" from 'Byte' to 'Word' we got an error message.) I'm not certain how we can get more 'Word' definiiton sapce without changing another 'Word' command line... and I'm not inclined to do that because it seems like the program is working pretty well right now.
Well, contemplating what Sylvie and Mr. Kibler said, could we let go of some VAR to a smaller size? I mean, worse come to worse, we would have to upgrade yet again to a larger stamp, which I am sure there are some. Are there some VAR we could downsize?
Attached is a graph of the data Chris and I got after running the ASP-BOE-CO all night, from 1:00 AM until 8:30 AM. We went to bed at 1:00 AM; scientists are curious, committed, and sometimes a bit eccentric. Also attached is a small sample of the 8 -1/2 hours of data, to show the variation in the "CO2" values (is it CO2 or millivolts...?) we deleted data in the temperature, humidity, and altitude columns because they are irrelevant for now.
The graph looks promising and the ASP-BOE "seems" to wired correctlly (or at least better than it was yesterday morning) But we're not 100% certain that the "CO2" data does, in fact, represent CO2. *NOTE (in the post above) that we've REVERSED the ALM and CNTL wires at p3 and p4 on the ASP-BOE.
Tracy and Paul,
Answer: The sample number resets to 0 at 255. How do we "buy" more 'Word' definition space (so we can change 'Bytes' to 'Words'?) I'm not sure exactly why we would want to do, but it would be good learning to understand how. Rocketeers, why WOULD we want to change 'Bytes" to 'Words"?
Finally, in the overall scheme of things, how does the program and ASP-BOE seem to be working to you at this juncture? What should you think we should "tweak", where, and why? Defining the ALM and CNTL as PINs allowed us to see CO2 (?) data on the computer screen (we dropped CH0 and CH1 as PIN definitions). But is it CO2 millivoltage we're seeing? The 8-1/2 hour data graph seems to support that conclusion (since plants output CO2 at different rates during the night and day because of photosynthesis. Note that the graph trendline is polynomial and that it represents a diurnal change.) I'm not sure what to make of having to switch the p3 and p4 (ALM and CNTL) wires around on the BOE to get it to work though.
It was a long and productive day (and night) yesterday. We seem to be on much more solid ground now (and I put the 'hammer away.) I will take Chris out to lunch to thank him and to celebrate our progress a bit (knock on wood!)
Assuming the CO2 data does in fact represent CO2, maybe adding a polynomial trendline is a simple solution to "averaging out" the fluctuations in the mV/CO2 readings (see graph below.) Or should we try for better resolution?
Yes, I believe this is correct data at first analysis. The CO2 concentrations, "should" drop due to slower human breathing rates and photosynthesis rates also decreasing in lack of sunlight resulting in less energy for the plant to produce oxygen. The slow rise would be due to human heart rates increasing, due to activities, therefor requiring more oxygen, then breathing out more CO2... Same effect for the plants but with photosynthesis.
But for your second attachment, why are the levels fluctuating so badly? Where you and Christo hovering over it? This could cause heightened CO2 levels, and sense CO2 is more dense then air, the CO2 would sink down on top of the sensor, (unless you where working upside down for some reason?).
You have to learn how to recycle. Recycle variables that is. Here are my suggested changes to program.
1) Eliminate all the variables that mashed over from the demo routine. That is, delete mVolts0, mVolts1, result0, result1. That frees up three Word-size variables.
2) The MCP_get subroutine has big changes.
Observe that the deleted variables are gone, and the only variable is CO2pp. It is going to be recycled. Observe also that the subroutine order is switched around. First it reads channel 1 and then channel 0 on the ADC. (The ADC doesn't care which channel you read first).
It reads channel 1 using CO2pp to capture the result, then recycles CO2pp in the conversion to millivolts. (This is an assignment statement, remember, not a statement of mathematical equality.) Then it prints the value of CO2pp, which at this point is the voltage from the TP3 potentiometer.
Then the subroutine reads channel 0, and in doing so it recycles CO2pp for the result, the conversion, and for the DEBUG. This though is the final value that remains in the variable CO2pp and ends up on the flash drive. It doesn't matter that CO2pp has been used in all sorts of different ways prior to that in the program. Note that CO2pp is also used in the carbon_collect subroutine to read the alarm status. That comes before MCP_get in your main program loop.
'---- [noparse][[/noparse] carbon VAR Word ] ----
' uses variable CO2pp. The other variables mVolts0, mVolts1, result0, result1 are DELETED
' -----[noparse][[/noparse] Carbon dioxide ]-----
' Added June 11, 2010 - Tracy, Dylan, Justin
Carbon_collect:
HIGH 4 'This activates the Heat Switch (HSW)
' <--- this does not really need to be repeated, but it doesn't hurt
CO2pp = IN3 ' read the CO2 level. Later, we will make this do more than just the alarm status
DEBUG TAB, DEC CO2pp ' show the CO2 level
RETURN
' -----[noparse][[/noparse] MCP3202 ADC ]-----
' Added June 14, 2010 by Andrew from Tracy
MCP_get:
' read channel 1 first, potentiometer, will not be logged
LOW CS ' Enable ADC
SHIFTOUT DataIn, Clock, MSBFIRST, [noparse][[/noparse] %1111\4] ' Select CH1, Single-Ended
SHIFTIN DataOut, Clock, MSBPOST, [noparse][[/noparse] CO2pp\12] ' Read ADC
HIGH CS ' Disable ADC
CO2pp = CO2pp */ Cnts2Mv ' Convert To Millivolts
DEBUG TAB, DEC CO2pp ' show the potentiometer voltage
' read channel 0, CO2 voltage, variable CO2pp will be logged on flash drive
LOW CS ' Enable ADC
SHIFTOUT DataIn, Clock, MSBFIRST, C[noparse][[/noparse] %1101\4] ' Select CH0, Single-Ended
SHIFTIN DataOut, Clock, MSBPOST, [noparse][[/noparse] CO2pp\12] ' Read ADC
HIGH CS ' Disable ADC
CO2pp = CO2pp */ Cnts2Mv ' Convert To Millivolts
DEBUG TAB, DEC CO2pp ' show the CO2 voltage
RETURN
Congratulations on logging the readings. The readings do seem a bit low, in addition to being noisy. Do you have Vin on the CO2 sensor connected to Vin on the BOE/ASP?
I'll attach my latest pictorial of how I think it is hooked up. Of course the exact placement of components and colors of wires does not matter! The BOE I am using here is an old model, so it might not be exactly the same as yours.
I made a couple of little edits in the above posts.
I don't understand the confusion about pns for CNTL and ALR. Originally we had CNTL to p4 and ALR to p3, I think. The important thing is simply that the hardware has to match the software. There is no great mystery about it. It could be p4 and p3 or it could be p3 and p4, just as long as the logical pin assignments match what the pins are actually connected to on the hardware.
I think the output of the CO2 sensor may simply be noisy. Intrinsic noise. This is often the single factor that limits our ability to measure things. If it is as noisy as it appears to be in your graph, we won't gain much by increasing the resolution of the analog to digital converter. Once we are sure the readings are good, I'll show you how to do averaging. Those extra word variables are going to come in handy. Your idea of averaging in Excel is also a solution for processing data after the flight.
You said :"Then the subroutine reads channel 0, and in doing so it recycles CO2pp for the result..."
So when CO2pp is recycled, is it deleted like you deleted the others so we can use 'Words'? I am confused about this, can you please explain it?
Thank you all for your time and help,
Sean
Hi Sean!
·· Good to see you on the forum. How's baseball going? What position do you play? Is it a WAC team or a JSRHS summer team (or neither?) How's your team doing this season?
Here's what I believe Dr. Allen meant when he said, "...the subroutine reads channel 0, and in doing so it recycles CO2pp for the result." I think he meant that CH0 reads the CO2 voltage first, then other subroutines (other parts of the program) use the same CO2 voltage after that. So the other subroutines "recycle" (reuse) the same CO2 information further along in the program.
I'm curious if my understanding and explanation match what·Dr. Allen·meant. If so, then we've both learned something new! If not, then follow what he says (and disregard what I wrote as nonsense~!)
I'm eager to add Dr. Allen's latest subroutine to the program when I get home. I both curious and eager to see what it does. We're doing really, really well this project year, thanks to some excellent and dedicated friends and mentors (Sylvie and Dr. Allen.) Keep up the good work Sean, and have fun at baseball too. I'm very·pleased to see that you're staying involved on the forum.
Here's what I believe Dr. Allen meant when he said, "...the subroutine reads channel 0, and in doing so it recycles CO2pp for the result." I think he meant that CH0 reads the CO2 voltage first, then other subroutines (other parts of the program) use the same CO2 voltage after that. So the other subroutines "recycle" (reuse) the same CO2 information further along in the program.
He's specifically talking about using the same variable twice, thus saving variable space. Here's the key line in the code:
CO2pp = CO2pp */ Cnts2Mv ' Convert To Millivolts
Notice that the variable CO2pp is on both sides of the assignment statement. You could have had something like this instead:
CO2pp = mVolts0 */ Cnts2Mv ' Convert To Millivolts
I think that's what you originally had. You read the millivolts value from the 3202 into mVolts0, and then converted that value into a new value in CO2pp.·But then you'd need two separate variables, CO2pp and mVolts0. You really only need the one variable. You read the millivolts value from the 3202 into CO2pp, and then just keep using that variable. The assignment statement CO2pp = CO2pp */ Cnts2Mv takes the current value of CO2pp, does a little math with it, and then replaces that variable's value with the value that results from the math.
So it's not that you're recycling information - you're recycling a variable, using it for one purpose, and then when it has served that purpose, using it for a new purpose. If you're careful, you can do that within a single line of code, as he has done here.
Post Edited (sylvie369) : 6/30/2010 7:37:36 PM GMT
Sylvie hit the nail on the head. Okay, nails are a harder to recycle than variables. My own grandmother used to take a lot of time to pull old nails out of boards when the thing they were holding together no longer needed to be held together, and then she would carefully straighten the nail and then use it for something else. She ran a boarding house in Oklahoma during the depression and that is where she learned recycling in a lot more intensive form than we know it today. But I digress.
A variable is just a location in memory where the program can store information. When a piece of information is not needed any more, the memory location where it is stored in can be reused for something else. The memory location is like the nail, and the information is like the thing the nail was holding together that is no longer needed. Electrons are very light weight and we don't need to do anything to pull out the old information or to straighten out the memory location. We only have to assign new data to the location, and viol
If you ever do create some type of robot maybe that did need more then the amount of WORDs that the stamp could hold, what would you do? Get another stamp, upgrade your current one?
You said that each piece of information has its own resting place, but can be shared with another. Is there a limit to how much information you can share with eachother?
You said that each piece of information has its own resting place, but can be shared with another. Is there a limit to how much information you can share with eachother?
Justin
Justin,
I could have misunderstood what has been said, but I believe any limitations on recycling/sharing variables would be logic-related, if that makes any sense. As Dr. Allen said, a variable is simply a storage location for some numbers. So long as those numbers stored are no longer needed, they can be erased and the variable space can be used to store a different number, for a different purpose. Am I interpreting this concept correctly?
Justin,
I agree with Andrew. It would be a logical answer, you can only share up to the size of the variable that you are sharing from. If you are sharing a WORD, you can't share more then a WORD from that WORD. Unless you mean how many times can you share it?
Post Edited (Dylan Landry) : 6/30/2010 11:58:45 PM GMT
We finally managed to isolate the "fly in the ointment!" Rocketeers, this an 'idiomatic expession.' No flies nor ointment was involved, only a few hours and some critical thinking. This idiomatic expression means "We found the problem."
Tracy, your condensed program works great! Thank you writing the code and teaching us about "Word", "Bytes", and "variables". I'll post the version of it that we're using at this end so we're all on the same digital page. Christopher figured out where in your program, and how, to "turn off" the potientiometer mV and alarm status (0 and 1) output to the flash drive, then turn it back on again. This may seem like a relatively small thing but collectively we're learning a heck of a lot!
** TRACY and SYLVIE ** - We found the problem with getting erratic CO2 mV, "the fly in the ointment" (finally!) It's remedied when we comment out ("shut off") the HIGH 4 command line that runs the heater (CNTL.) When we un-comment HIGH 4 (turn it back on) the problem reappears: CO2 mV drops to '0' and stays there.
We suspected faulty soldering in our homemade 4-hole female (DIP switch?) wiring harness so we switched to another wiring harness and got the exact same results. We also switched CO2 sensors and modules around and the same thing occurs predictably. The problem then, (at this end anyway) seems to be the HIGH 4 command line (which we need, right? It turns the heater on, doesn't it?)
In the final analysis we'd like to keep the potientiometer mV output going to the flash drive. It's already in the program, it works, it shouldn't hurt anything by keeping it there (should it?), and it would be another piece of potentially valuable flight data from the "ASP-BOE-CO-POTmV."
What are your thoughts on the HIGH 4 bugaboo? Any ideas why the CO2 mV drops when the HIGH 4/ heater is on?
I'm going out for a much-need run on this chilly New Hampshire evening. I'll check in later. Thanks.
Attached is the program we're currently running (June 30, 2010) so that we're all using the same version, and since it changes almost daily. It includes Tracy's new and improved program changes:
"Eliminated all the variables from the demo routine (commenetd out mVolts0, mVolts1, result0, result1.)" - Check -
"The MCP_get subroutine has big changes... the deleted variables are gone and the only variable is CO2pp. Also the subroutine order is switched around." - Check -
We commenetd out the 'HIGH 4' subroutine that turns the CO2 heater on. It seems to be responsible for corrupting the CO2 mV/pp readings. We're not sure how to remedy this glitch. Are the CO2 heater (and the HIGH 4 command) essential to proper CO2 sensor function (especially in the desert?) It seems prudent to leave 'HIGH 4' on, but how...?
Another fun day at the tree farm!. You guys are the best!
... So what are the units that appear as CO2 'ppm' in the current program? Are they volts or millivolts?... ? We need to be sure so they can be converted into parts per million (ppm) of CO2 in the program/ formula.
I thought they where neither? They, "were" mV but they got multiplied by the ADC. By my understanding they are an undefined unit of measurement (Not as much a ft and what not). Am I on the right path? Or the wrong one? Unless the formula was taken out and I missed something. Then it would be mV. If you could send me a screenshot of the program's (the one you posted last) exact data output that would be great. It would help us perform a higher quality analysis.
Post Edited (Dylan Landry) : 7/1/2010 3:49:33 AM GMT
a variable is simply a storage location for some numbers. So long as those numbers stored are no longer needed, they can be erased and the variable space can be used to store a different number, for a different purpose. Am I interpreting this concept correctly?
Yes. Exactly!
Dylan said said...
Justin,
I agree with Andrew. It would be a logical answer, you can only share up to the size of the variable that you are sharing from. If you are sharing a WORD, you can't share more then a WORD from that WORD. Unless you mean how many times can you share it?
Justin said said...
Dylan,
Yes that's what I meant. How many times can you share it? Is it limited?
There are important ideas in that discussion and give and take. I hope you continue to think about it and figure it out. The variables do have sizes. A word variable holds 16 bits under one name and it can hold any of the other sizes. But you can't cram a large word-size number like 4095 into a byte-size variable, which can hold numbers only as high as 255. Nibbles can only hold up to 15, and Bits only 0 or 1. You are talking here about RAM memory, (Random Access Memory) and there is no limitation on how often they can be shared. I think by "share" you mean "write new and frequently changing information to it". There is no limitation at all for RAM memory. However, the Stamp does have another kind of memory, where the program itself is stored and also some data. It is EEPROM (electrically eraseable read only memory). EEPROM does have a limit on the number of times it can be altered. Something like a million times. You change that EEPROM every time you reload the program using the RUN command on the PC. That is kind of like "sharing" the same memory sequentially for different programs. It is going to be a long time before you reprogram your Stamp a million times!
The readings are in milliVolts, or at least they should be. The ADC reads a count from 0 to 4095, and then the program effectively multiplies that times 1.2207 to convert the count to milliVolts. If you have a digital multimeter, you should be able to connect that to TP1 (the multimeter red lead, with the black lead to Vss), and it should read almost exactly the same as the program displays on the DEBUG screen.
Mark said...
We commenetd out the 'HIGH 4' subroutine that turns the CO2 heater on. It seems to be responsible for corrupting the CO2 mV/pp readings. We're not sure how to remedy this glitch. Are the CO2 heater (and the HIGH 4 command) essential to proper CO2 sensor function (especially in the desert?) It seems prudent to leave 'HIGH 4' on, but how...?
Hmmmmm???? Something is hooked up wrong. Are you sure you don't have pins p3 and p4 mixed up still?
Here is a graph I made this evening with a CO2 sensor and readings taken at 1 second intervals. It takes quite a long time for the sensor to warm up.
What excellent data and an excellent graph yours is! I wish ours looked like that, but not yet. This morning we built another stand-alone CO2 sensor set-up on a BOE and we wired it 'exactly' like your detailed color schematic shows. At the same time we ran the ASP-BOE-CO set-up so we had two going at once.
1) We let the heater warm up for 25 minutes (and the metal sensor part was hot)
2) HIGH 3 was on
3) TP1 to CH0, to 3 to CH1
4) ALM to p3 and CNTL (HSW) to p4
We got the same results as before on both and something seems fishy at this end It isn't fish and we will continue to trouble shoot.
Where do you suggest that we look? We've examined and reexamined the wiring. Could it be something about the resistors? The capacitor?
Christopher has them both running in tandem right now as we did earlier this morning. Hopefull we won't get the same results (but why wouldn't we; nothing has been changed!)
======================================
Do you have any big plans for the holiday weekend? Hiking, biking, or barbeque-ing? I wonder if Sylvie will go to any minor league baseball games? Do you watch baseball much? We see 3-4 games every summer, both minor and major league. We're headed over to Maine for 3-4 days and maybe we'll watch the Portland Sea Dogs play. Then I'm headed out-of-state for the better part of a month. The ASP-BOE-CO goes wherever I go. Figuring out the ASP-BOE is like doing one of those 'cryptoquote" puzzles where one letter = another letter (A = M, S = B, etc.) and you have to figure out what the scrambled quote says. Except the ASP-BOE cryptoquote has more than 26 letters... and it also has bits, nbbles, bytes, adn words. Thanks for explaining the progression from smaller to larger by name. I understand the cotinuum (bits to bytes to words) much better now. I hope the other Rocketeers do, too.
Comments
Mr. Kibler,
Thanks for re-uploading the graph, it worked this time. Although we aren't quite there yet, everything looks very promising! As for your first point, I understand what you are saying but I am not sure how we would fix or compensate for it. As for your second point, I am guessing that this would be an issue with the variable size, as Dylan suggested in the post above mine. However, I am not entirely certain.
Good morning,
Andrew
If you needed to count higher than that, what might you add to the program?
Hint: it'd be quite easy, assuming you're not already out of variable space.
Dylan,
This is insightful and it sounds like you're learning some things! Check my post to Dr. Allen and Sylvie above though, and you'll notice that we're out of "Word" definition space (e.g. when Chris and I changed "mVolts0" from 'Byte' to 'Word' we got an error message.) I'm not certain how we can get more 'Word' definiiton sapce without changing another 'Word' command line... and I'm not inclined to do that because it seems like the program is working pretty well right now.
Any ideas?
Mr. Kibler
Attached is a graph of the data Chris and I got after running the ASP-BOE-CO all night, from 1:00 AM until 8:30 AM. We went to bed at 1:00 AM; scientists are curious, committed, and sometimes a bit eccentric. Also attached is a small sample of the 8 -1/2 hours of data, to show the variation in the "CO2" values (is it CO2 or millivolts...?) we deleted data in the temperature, humidity, and altitude columns because they are irrelevant for now.
The graph looks promising and the ASP-BOE "seems" to wired correctlly (or at least better than it was yesterday morning) But we're not 100% certain that the "CO2" data does, in fact, represent CO2. *NOTE (in the post above) that we've REVERSED the ALM and CNTL wires at p3 and p4 on the ASP-BOE.
Tracy and Paul,
Answer: The sample number resets to 0 at 255. How do we "buy" more 'Word' definition space (so we can change 'Bytes' to 'Words'?) I'm not sure exactly why we would want to do, but it would be good learning to understand how. Rocketeers, why WOULD we want to change 'Bytes" to 'Words"?
Finally, in the overall scheme of things, how does the program and ASP-BOE seem to be working to you at this juncture? What should you think we should "tweak", where, and why? Defining the ALM and CNTL as PINs allowed us to see CO2 (?) data on the computer screen (we dropped CH0 and CH1 as PIN definitions). But is it CO2 millivoltage we're seeing? The 8-1/2 hour data graph seems to support that conclusion (since plants output CO2 at different rates during the night and day because of photosynthesis. Note that the graph trendline is polynomial and that it represents a diurnal change.) I'm not sure what to make of having to switch the p3 and p4 (ALM and CNTL) wires around on the BOE to get it to work though.
It was a long and productive day (and night) yesterday. We seem to be on much more solid ground now (and I put the 'hammer away.) I will take Chris out to lunch to thank him and to celebrate our progress a bit (knock on wood!)
Mark
Assuming the CO2 data does in fact represent CO2, maybe adding a polynomial trendline is a simple solution to "averaging out" the fluctuations in the mV/CO2 readings (see graph below.) Or should we try for better resolution?
Mark
1) Eliminate all the variables that mashed over from the demo routine. That is, delete mVolts0, mVolts1, result0, result1. That frees up three Word-size variables.
2) The MCP_get subroutine has big changes.
Observe that the deleted variables are gone, and the only variable is CO2pp. It is going to be recycled. Observe also that the subroutine order is switched around. First it reads channel 1 and then channel 0 on the ADC. (The ADC doesn't care which channel you read first).
It reads channel 1 using CO2pp to capture the result, then recycles CO2pp in the conversion to millivolts. (This is an assignment statement, remember, not a statement of mathematical equality.) Then it prints the value of CO2pp, which at this point is the voltage from the TP3 potentiometer.
Then the subroutine reads channel 0, and in doing so it recycles CO2pp for the result, the conversion, and for the DEBUG. This though is the final value that remains in the variable CO2pp and ends up on the flash drive. It doesn't matter that CO2pp has been used in all sorts of different ways prior to that in the program. Note that CO2pp is also used in the carbon_collect subroutine to read the alarm status. That comes before MCP_get in your main program loop.
'---- [noparse][[/noparse] carbon VAR Word ] ---- ' uses variable CO2pp. The other variables mVolts0, mVolts1, result0, result1 are DELETED ' -----[noparse][[/noparse] Carbon dioxide ]----- ' Added June 11, 2010 - Tracy, Dylan, Justin Carbon_collect: HIGH 4 'This activates the Heat Switch (HSW) ' <--- this does not really need to be repeated, but it doesn't hurt CO2pp = IN3 ' read the CO2 level. Later, we will make this do more than just the alarm status DEBUG TAB, DEC CO2pp ' show the CO2 level RETURN ' -----[noparse][[/noparse] MCP3202 ADC ]----- ' Added June 14, 2010 by Andrew from Tracy MCP_get: ' read channel 1 first, potentiometer, will not be logged LOW CS ' Enable ADC SHIFTOUT DataIn, Clock, MSBFIRST, [noparse][[/noparse] %1111\4] ' Select CH1, Single-Ended SHIFTIN DataOut, Clock, MSBPOST, [noparse][[/noparse] CO2pp\12] ' Read ADC HIGH CS ' Disable ADC CO2pp = CO2pp */ Cnts2Mv ' Convert To Millivolts DEBUG TAB, DEC CO2pp ' show the potentiometer voltage ' read channel 0, CO2 voltage, variable CO2pp will be logged on flash drive LOW CS ' Enable ADC SHIFTOUT DataIn, Clock, MSBFIRST, C[noparse][[/noparse] %1101\4] ' Select CH0, Single-Ended SHIFTIN DataOut, Clock, MSBPOST, [noparse][[/noparse] CO2pp\12] ' Read ADC HIGH CS ' Disable ADC CO2pp = CO2pp */ Cnts2Mv ' Convert To Millivolts DEBUG TAB, DEC CO2pp ' show the CO2 voltage RETURN▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 6/30/2010 5:30:31 PM GMT
I'll attach my latest pictorial of how I think it is hooked up. Of course the exact placement of components and colors of wires does not matter! The BOE I am using here is an old model, so it might not be exactly the same as yours.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 6/30/2010 5:20:41 PM GMT
I don't understand the confusion about pns for CNTL and ALR. Originally we had CNTL to p4 and ALR to p3, I think. The important thing is simply that the hardware has to match the software. There is no great mystery about it. It could be p4 and p3 or it could be p3 and p4, just as long as the logical pin assignments match what the pins are actually connected to on the hardware.
I think the output of the CO2 sensor may simply be noisy. Intrinsic noise. This is often the single factor that limits our ability to measure things. If it is as noisy as it appears to be in your graph, we won't gain much by increasing the resolution of the analog to digital converter. Once we are sure the readings are good, I'll show you how to do averaging. Those extra word variables are going to come in handy. Your idea of averaging in Excel is also a solution for processing data after the flight.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
You said :"Then the subroutine reads channel 0, and in doing so it recycles CO2pp for the result..."
So when CO2pp is recycled, is it deleted like you deleted the others so we can use 'Words'? I am confused about this, can you please explain it?
Thank you all for your time and help,
Sean
·· Good to see you on the forum. How's baseball going? What position do you play? Is it a WAC team or a JSRHS summer team (or neither?) How's your team doing this season?
Here's what I believe Dr. Allen meant when he said, "...the subroutine reads channel 0, and in doing so it recycles CO2pp for the result." I think he meant that CH0 reads the CO2 voltage first, then other subroutines (other parts of the program) use the same CO2 voltage after that. So the other subroutines "recycle" (reuse) the same CO2 information further along in the program.
I'm curious if my understanding and explanation match what·Dr. Allen·meant. If so, then we've both learned something new! If not, then follow what he says (and disregard what I wrote as nonsense~!)
I'm eager to add Dr. Allen's latest subroutine to the program when I get home. I both curious and eager to see what it does. We're doing really, really well this project year, thanks to some excellent and dedicated friends and mentors (Sylvie and Dr. Allen.) Keep up the good work Sean, and have fun at baseball too. I'm very·pleased to see that you're staying involved on the forum.
Mr. Kibler
Notice that the variable CO2pp is on both sides of the assignment statement. You could have had something like this instead:
I think that's what you originally had. You read the millivolts value from the 3202 into mVolts0, and then converted that value into a new value in CO2pp.·But then you'd need two separate variables, CO2pp and mVolts0. You really only need the one variable. You read the millivolts value from the 3202 into CO2pp, and then just keep using that variable. The assignment statement CO2pp = CO2pp */ Cnts2Mv takes the current value of CO2pp, does a little math with it, and then replaces that variable's value with the value that results from the math.
So it's not that you're recycling information - you're recycling a variable, using it for one purpose, and then when it has served that purpose, using it for a new purpose. If you're careful, you can do that within a single line of code, as he has done here.
Post Edited (sylvie369) : 6/30/2010 7:37:36 PM GMT
A variable is just a location in memory where the program can store information. When a piece of information is not needed any more, the memory location where it is stored in can be reused for something else. The memory location is like the nail, and the information is like the thing the nail was holding together that is no longer needed. Electrons are very light weight and we don't need to do anything to pull out the old information or to straighten out the memory location. We only have to assign new data to the location, and viol
You said that each piece of information has its own resting place, but can be shared with another. Is there a limit to how much information you can share with eachother?
Justin
Justin,
I could have misunderstood what has been said, but I believe any limitations on recycling/sharing variables would be logic-related, if that makes any sense. As Dr. Allen said, a variable is simply a storage location for some numbers. So long as those numbers stored are no longer needed, they can be erased and the variable space can be used to store a different number, for a different purpose. Am I interpreting this concept correctly?
Andrew
I agree with Andrew. It would be a logical answer, you can only share up to the size of the variable that you are sharing from. If you are sharing a WORD, you can't share more then a WORD from that WORD. Unless you mean how many times can you share it?
Post Edited (Dylan Landry) : 6/30/2010 11:58:45 PM GMT
We finally managed to isolate the "fly in the ointment!" Rocketeers, this an 'idiomatic expession.' No flies nor ointment was involved, only a few hours and some critical thinking. This idiomatic expression means "We found the problem."
Tracy, your condensed program works great! Thank you writing the code and teaching us about "Word", "Bytes", and "variables". I'll post the version of it that we're using at this end so we're all on the same digital page. Christopher figured out where in your program, and how, to "turn off" the potientiometer mV and alarm status (0 and 1) output to the flash drive, then turn it back on again. This may seem like a relatively small thing but collectively we're learning a heck of a lot!
** TRACY and SYLVIE ** - We found the problem with getting erratic CO2 mV, "the fly in the ointment" (finally!) It's remedied when we comment out ("shut off") the HIGH 4 command line that runs the heater (CNTL.) When we un-comment HIGH 4 (turn it back on) the problem reappears: CO2 mV drops to '0' and stays there.
We suspected faulty soldering in our homemade 4-hole female (DIP switch?) wiring harness so we switched to another wiring harness and got the exact same results. We also switched CO2 sensors and modules around and the same thing occurs predictably. The problem then, (at this end anyway) seems to be the HIGH 4 command line (which we need, right? It turns the heater on, doesn't it?)
In the final analysis we'd like to keep the potientiometer mV output going to the flash drive. It's already in the program, it works, it shouldn't hurt anything by keeping it there (should it?), and it would be another piece of potentially valuable flight data from the "ASP-BOE-CO-POTmV."
What are your thoughts on the HIGH 4 bugaboo? Any ideas why the CO2 mV drops when the HIGH 4/ heater is on?
I'm going out for a much-need run on this chilly New Hampshire evening. I'll check in later. Thanks.
This is so fun!
Mark
Yes that's what I meant. How many times can you share it? Is it limited?
Justin
"Eliminated all the variables from the demo routine (commenetd out mVolts0, mVolts1, result0, result1.)" - Check -
"The MCP_get subroutine has big changes... the deleted variables are gone and the only variable is CO2pp. Also the subroutine order is switched around." - Check -
We commenetd out the 'HIGH 4' subroutine that turns the CO2 heater on. It seems to be responsible for corrupting the CO2 mV/pp readings. We're not sure how to remedy this glitch. Are the CO2 heater (and the HIGH 4 command) essential to proper CO2 sensor function (especially in the desert?) It seems prudent to leave 'HIGH 4' on, but how...?
Another fun day at the tree farm!. You guys are the best!
Good night,
Mark, Chris and Rocketeers from near and far
Post Edited (Dylan Landry) : 7/1/2010 3:49:33 AM GMT
There are important ideas in that discussion and give and take. I hope you continue to think about it and figure it out. The variables do have sizes. A word variable holds 16 bits under one name and it can hold any of the other sizes. But you can't cram a large word-size number like 4095 into a byte-size variable, which can hold numbers only as high as 255. Nibbles can only hold up to 15, and Bits only 0 or 1. You are talking here about RAM memory, (Random Access Memory) and there is no limitation on how often they can be shared. I think by "share" you mean "write new and frequently changing information to it". There is no limitation at all for RAM memory. However, the Stamp does have another kind of memory, where the program itself is stored and also some data. It is EEPROM (electrically eraseable read only memory). EEPROM does have a limit on the number of times it can be altered. Something like a million times. You change that EEPROM every time you reload the program using the RUN command on the PC. That is kind of like "sharing" the same memory sequentially for different programs. It is going to be a long time before you reprogram your Stamp a million times!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 7/1/2010 5:19:18 AM GMT
Hmmmmm???? Something is hooked up wrong. Are you sure you don't have pins p3 and p4 mixed up still?
Here is a graph I made this evening with a CO2 sensor and readings taken at 1 second intervals. It takes quite a long time for the sensor to warm up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
What excellent data and an excellent graph yours is! I wish ours looked like that, but not yet. This morning we built another stand-alone CO2 sensor set-up on a BOE and we wired it 'exactly' like your detailed color schematic shows. At the same time we ran the ASP-BOE-CO set-up so we had two going at once.
1) We let the heater warm up for 25 minutes (and the metal sensor part was hot)
2) HIGH 3 was on
3) TP1 to CH0, to 3 to CH1
4) ALM to p3 and CNTL (HSW) to p4
We got the same results as before on both and something seems fishy at this end It isn't fish and we will continue to trouble shoot.
Where do you suggest that we look? We've examined and reexamined the wiring. Could it be something about the resistors? The capacitor?
Christopher has them both running in tandem right now as we did earlier this morning. Hopefull we won't get the same results (but why wouldn't we; nothing has been changed!)
======================================
Do you have any big plans for the holiday weekend? Hiking, biking, or barbeque-ing? I wonder if Sylvie will go to any minor league baseball games? Do you watch baseball much? We see 3-4 games every summer, both minor and major league. We're headed over to Maine for 3-4 days and maybe we'll watch the Portland Sea Dogs play. Then I'm headed out-of-state for the better part of a month. The ASP-BOE-CO goes wherever I go. Figuring out the ASP-BOE is like doing one of those 'cryptoquote" puzzles where one letter = another letter (A = M, S = B, etc.) and you have to figure out what the scrambled quote says. Except the ASP-BOE cryptoquote has more than 26 letters... and it also has bits, nbbles, bytes, adn words. Thanks for explaining the progression from smaller to larger by name. I understand the cotinuum (bits to bytes to words) much better now. I hope the other Rocketeers do, too.
Still stumped,
Mark