In that attached program, "Clock" is a constant referring to pin 14, which I believe you have been connecting to 3202's clk pin (pin 7). The fact that it's named Clock has nothing to do with the real time clock... there needs to be a pin used as the clock pin to coordinate the timing of the bits of data sent and received. You have pins 0 and 2 as the clock pins for the SHT11 and the RTC chip, respectively: they're identified as shtclk and dsclk. ·
So assuming that BoE pin 14 is connected to 3202 pin 7, this is not the source of your problem.
BINGO! We have a lucky winner!
Thanks for rattling my brains around, Paul! And thanks for holding off and lettingme figure this one out, Tracy. You guys are great. Paul, your last post caused me to approach the dilemma from a different angle and the fly in the ointment was (lo and behold) misnamed/misplaced wires, not an error in the program.·Andrew, it·seem that·your (and Dr. Allen's) "mash-up" program WORKS!·(*better hire him or get him a scholarship Tracy, before he gets an offer from MIT. He'd do well at Berkeley or Cal-Tech.)
Paul, when you mentioned that the pin numbers were different·("...referring to pin 14, which I believe you have been connecting to 3202's clk, which is·pin 7")··I went back and·compared which pin·each wire went to versus·what it said in the (attached) program.·And there the problem was. Three wires were going to the wrong pins!
As soon as I moved the three wires to match the I/O definitions in the program, "good" numbers appeared (voltages below 3.1, etc.) To confirm that it was working I did as Tracy suggested: I dialed the potientiometer screw clockwise and counterclockwise and watched the voltage (and its corresponding number) increase and decrease. I also blew "pure" CO2 into the sensor (from an aerosol·CO2 cartridge) and the other set of numbers responded accordingly. I'm giddy (my wife thinks I'm goofy most of the time so she can't tell.)
Soooooooooooooooooooo.!
I'll post the wiring scheme that goes with the attached program so Andrew and the other Rocketeers can build their ASP-clones at home and run·them with a good degree of confidence that·they will work. I'm headed back into the "lab" (the dining room table) to tinker with the ASP-clone, the wires, and the program a bit more. I believe we've·crossed a·big hurdle together.
Woo-hoo! That's great! I was really worried that something was wrong that would take weeks to figure out. Great to hear that it's working properly.
A comment: if you're trying to read an analog pin and your readings are all 0, 255, 512, 4096 and so on (that is, powers of 2, or one less), there's something wrong with your wiring, probably. It could be the programming. It's very likely NOT legitimate voltage readings.
Spain wins, and both Spain and Chile move on. I'm rooting for Spain.
Attached is a "cleaner", easier to read, more professional looking version of the same program I just posted,which works pretty well. I will upload the wire·schematic so you can·finish building your·ASP-clone at home.
Please download·the program·and·examine it closely to see how we can make·the program·work even better. Andrew, please facilitate the discussion and explain to your new teammates any changes you propose, and why.
Pros:
1) "Adjustment voltage" (and its accompanying numbers) reads out to the computer screen and·changes·when the CO2 sensor's potientiometer is adjusted.
2) "CO2 voltage" and its number also appear on the computer screen. CO2 millivoltage is low-- from about 0.05 to 0.250 +/-·mV (as expected with low ambient·CO2 concentration).
3) The MAWDBOE data (sample number, elasped time, temperature, humidity, and altitude) appear on the screen·in columns and are written to the flash drivejust fine.
Cons:
1) The CO2 "number" correlated with voltage increases when voltage increases. Shouldn't it decrease? (since the relationship between millivoltage and CO2 concentration is inverse, according to the graph in the documentation.) I'm not sure whether CO2 is really being measured...
2) The COs voltages and numbers appear right on top of the MAWDBOE data on the computer screen.
3) When the data is downloaded from the flash drive it is still binary (1's and 0's, not voltage/numbers.)
4) When the CO2 voltages and numbers appear on the screen,·the MAWDBOE data stops writing data·in columns on the screen. It's still·visible·but·it appears as one line of data only, and it's offset.·The data·still change as·they should and it still writes data·in columns to the flash drive.
Rocketeers, please offer your suggestions on how we can remedy these 'cons'. Download·the program·and look at it closely, and...
...if you're trying to read an analog pin and your readings are all 0, 255, 512, 4096 and so on (that is, powers of 2, or one less), there's something wrong with your wiring, probably.
Spain wins, and both Spain and Chile move on. I'm rooting for Spain.
Vive Espana! I don't speak Chilean so I can't say anything to cheer them on. So "Go Chile!" I think Tracy is in mourning for Italia! Italia! We should send him some Chianti and prosciutto to console him.How many teams are still·left? Which ones (Japan, Ghana and US for sure, Chile, Spain, and ...?)
Yes, I wondered why the (previous) voltages were all powers of 2 (high voltage was 4095(6) and·low voltage was 255(6)... exactly 1/16 of 4096. But I didn't want to ask such a 'simple' question. I wondered if it might indicate something like bad wiring... now you tell me!
So we roll into the weekend with that little bump smoothed over. It seems like such a big step though!. I just posted some pros and cons about the program, seemingly small things by comparison.
Andrew did a really good job of putting together the "mash-up" program from the various subroutines Tracy uploaded, don't you think?·I'm very pleased that it works so well. I was expecting at least a few more weeks of troubleshooting (knock on wood.)
I looked at the "CO2 concentration versus millivoltage" graph again and the inverse linear relationship between the two isn't quite linear. The graph line curves upward as mV increases and CO2 concentration decreases·on the left side of the graph. Now I understand why Tracy asked the Rocketeers about this a few weeks ago. How will we adjust for·a non-linear relationship in·the algorithm·in the program?·Ambient CO2 is relatively low, roughly 100-350 ppm. That CO2 concentration is off the graph line. Tracy knew weeks ago that we would need to know this weeks later. It's like he can see into the future! You and Tracy are geniuses. I am·honored just to walk in your shadows...
Any fun plans·for the weekend? I have yard work and house work to do, then we'll probably go for a jog or a hike or a bike ride at the state park at the end of our road. Don't stay up too late in cyber space! Vive Espana! Go Chile!
1) The CO2 "number" correlated with voltage increases when voltage increases. Shouldn't it decrease? (since the relationship between millivoltage and CO2 concentration is inverse, according to the graph in the documentation.) I'm not sure whether CO2 is really being measured..
Do you mean the number ranging from 0 to 4096 that comes from the 3202? That number SHOULD increase with the voltage. In fact, it has to, as it's the number used to compute the voltage.
Voltage on 3202's input pin --> Converted by 3202 to a unitless number from 0 to 4096 and sent to BoE --> Converted by your program to a voltage (units: volts or millivolts)·--> Converted by your program (eventually) to·CO2 level (units: ppm)
It's only on that last step that the inverse relationship will make a difference, and you will have to program it to take care of that. But the number from the 3202 will always have a positive correlation with the voltage on the 3202 input pin.
You wrote "CO2 millivoltage is low-- from about 0.05 to 0.250 +/-·mV (as expected with low ambient·CO2 concentration)."
You can see then why I was talking a couple of screens back about trying to make better use of your ADC's range. It can measure from 0 to 5 volts, but you're only encountering 0 to .25 volts, so more than 90% of your range is unused with this sensor. Again, that's not the end of the world, but if there were an easy way to make that 0-4096 represent (say) 0·to .5 volts, you'd have MUCH better resolution.
Another important comment: In your real application, you're not going to care about the setting of the potentiometer mounted on the CO2 sensor. It's only there to change the alarm setting, and you're not using the alarm, you're reading CO2 level directly from TP1. It's good that you're able to read that setting also, but there's no need for it in your program: it doesn't tell you anything about the outside world. It only tells you where you've left the onboard pot set.
En Chile se habla Espanol. Hay 16 equipos en el segundo parte del World Cup. Se puede verlos aqui:
Do you mean the number ranging from 0 to 4096 that comes from the 3202? That number SHOULD increase with the voltage.
Yes, the number from 0 to 4096 was the number I was referring to. So·showing it as·an inverse relationship is done in the programming then?·I just looked at the program and now I see·that there's an equation·to convert the·"numbers" into voltage: "mVolts0 = result0 */ Cnts2Mv". 'Result0' must be the number and '/Cnts2mv'·must mean 'converts to milllivolts' (or functions to do that.) Converting·from 0 - 4096 to·CO2 ppm is done·in a similar way then, with a forumla in the program. I think I get it.
You wrote "CO2 millivoltage is low-- from about 0.05 to 0.250 +/-·mV (as expected with low ambient·CO2 concentration).
Yes, that's correct. The·CO2 re"ading is between 0.05 and 0.250 +/- volts. If the maximum voltage·is 3.0 volts,·then the CO2 reading·is relatively low at 0.05 to 0.250. But I'll confirm the·reading later just to be sure.
You can see then why I was talking a couple of screens back about trying to make better use of your ADC's range... more than 90% of your range is unused with this sensor.·
Yes, that makes much more sense now. If the maximum possible voltage is 3.0+ volts and the maximum reading (currently...no pun intended) is 0.25 volts, then the range from 0.25 to 3.0 is, as you said, unused.
...if there were an easy way to make that 0-4096 represent (say) 0·to .5 volts, you'd have MUCH better resolution.
Yes, this makes sense too. The questions are, "How do you make 0 to 4096 represent 0.5 volts? How do you increase the resolution?" I recall a few pages back that Tracy said it·would require another converter (or something similar)... more electronics, more wires, more programming. I think we weighed the options between adding another converter or keeping what we haveas "good enough for our purposes." I'll re-read the conversation again but I think that was the gist of it.
So what are the options for better data resolution? I see three options·(but I wear glasses): 1) Add another converter as I just explained, or 2)·Adjust for·better resoultion in the program/algorithm. I'm not if sure that's a viable option. That's where I defer to you and Tracy. 3) Keep things 'as is', run the program, and see what we get for data/resolution. Then reconsider options #1 and #2 if need be.
...you're not going to care about the setting of the potentiometer mounted on the CO2 sensor. It's only there to change the alarm setting... there's no need for it in your program: it doesn't tell you anything about the outside world. It only tells you where you've left the onboard pot set.
You're right, and I also thought about that. So do we need to show the potientiometer voltage to be shown at all?·Right now it's really·good to have it so we can confirm that the CO2 sensor module is working. But does·potientiometer voltage ultimately·need to be shown? The flip side: will it harm anything adversely by keeping it there?
As I mentioned in the previous post, CO2 voltage isn't being written to flash drive as voltage. It's being written as "alarm status"" 1 or 0. Also, when it appears on the screen it's almost directly on top of the other data (temp, humidity, etc.) The temp-humidity-time data stops writing as separate lines of data on the screen, appearing instead as one line of data that changes properly every second. The data does write to the flash drive OK (CO2 as 1's and 0's.) This seems like a simple* task of program reformatting (*simple if you're an electronic engineering genius that is!)
Where do we go from here, now that the CO2 sensor reads out voltage? What do you see as the next step(s) in the project?
So is Chilean Spanish a regional dialect? Or·is 'classic' Spanish spoken and understood in·most South American countries? I thought perhaps that each country spoke a slightly different dialect. But having never been there I can only speculate.
16 teams left, huh? And at least two are from South America I see: Chile and Uruguay. I know this because I'm watching Uruguay beat Korea 1-0 as I eat my French toast (which is 'French' by name only. I have never eaten·French toast·in France. The closest thing is a Croque Monsieur, or crepes. They give me the creeps!)·Did you eat "Spanish toast" for breakfast in Chile...?
Another converter for a better resolution sounds great! However, like you said we already have something good enough for our purposes. A better resolution could really help us, but (excuse my arrogance) would that fall under that Occam's razor principle you told me about? About keeping things simple but "good enough"?
Yes, the number from 0 to 4096 was the number I was referring to. So·showing it as·an inverse relationship is done in the programming then?·I just looked at the program and now I see·that there's an equation·to convert the·"numbers" into voltage: "mVolts0 = result0 */ Cnts2Mv". 'Result0' must be the number and '/Cnts2mv'·must mean 'converts to milllivolts' (or functions to do that.) Converting·from 0 - 4096 to·CO2 ppm is done·in a similar way then, with a forumla in the program. I think I get it
Think about it this way: the 3202 looks at a voltage on an input pin that can range from 0 to Vdd (5 volts, in your case). It reports a digital number from 0·to 4095 that represents that voltage. That number can be 0, 1, 2, 3, 4, 5...4094, 4095. It splits the 5 volt range up into 4096 steps. Each step, then, represents 5/4096 volts. It's often easier to think about that in millivolts, so it's 5000/4096 millivolts per step, or 1.22 mV per step.
If you have a reading of 2048, you're halfway through the 5000 mV scale, and you should be able to see intuitively that the voltage is 2500 mV (2.5 volts), right? Using the equation instead of intuition, you have
mV = (2048/4096)*5000··· <--- in other words, (how far through the scale you are) * (how long the scale is).
Mark in NH said...
You can see then why I was talking a couple of screens back about trying to make better use of your ADC's range... more than 90% of your range is unused with this sensor.·
Yes, that makes much more sense now. If the maximum possible voltage is 3.0+ volts and the maximum reading (currently...no pun intended) is 0.25 volts, then the range from 0.25 to 3.0 is, as you said, unused
Actually the range is from 0 to 5 volts, or whatever voltage you're using to power the 3202. The 3202 chip doesn't know about the maximum voltage the sensor could put out. It allocates the number (0..4095) to a range from 0 volts to whatever voltage is applied to its Vdd pin (again, in your case, 5 volts).
Mark in NH said...
...if there were an easy way to make that 0-4096 represent (say) 0·to .5 volts, you'd have MUCH better resolution.
Yes, this makes sense too. The questions are, "How do you make 0 to 4096 represent 0.5 volts? How do you increase the resolution?" I recall a few pages back that Tracy said it·would require another converter (or something similar)... more electronics, more wires, more programming. I think we weighed the options between adding another converter or keeping what we haveas "good enough for our purposes." I'll re-read the conversation again but I think that was the gist of it.
So what are the options for better data resolution? I see three options·(but I wear glasses): 1) Add another converter as I just explained, or 2)·Adjust for·better resoultion in the program/algorithm. I'm not if sure that's a viable option. That's where I defer to you and Tracy. 3) Keep things 'as is', run the program, and see what we get for data/resolution. Then reconsider options #1 and #2 if need be.
The range that the 3202 divvies up the numbers over is determined by the voltage on its Vdd pin, so using a lower voltage there will give you more resolution. But there are two caveats: first, you have to give the 3202 enough voltage to work. If I remember correctly, it requires at least 2.7 V. Secondly, you would probably need to worry about the levels of the three data lines connecting the 3202 to the BoE. I think that's a killer, probably - complicated enough to make this not worth doing. But Tracy may know a simple way to do it (or even perhaps that it doesn't need to be done - that the BoE can read logic levels from a chip powered by 2.7 V).
There's also a chance you'd just be getting false resolution. As I said, the reference voltage is the voltage applied to the 3202's Vdd pin, and I've said a number of times that it's 5 V. But it's probably actually a few tens of millivolts higher than that. When I set mine up, the 5 V supply I used actually gave the 3202 5.06 volts, and so the true reading on the input pin would have been
mV = (number/4096) * 5060·· <--- not " * 5000 "
You could measure the actual input voltage and use that in your equation, and improve the accuracy a bit. Or you could just pretend that it's really 5V. Either way, it may wander a bit (this is what the capacitor is designed to minimize), and the wandering it does may be enough to make the increased resolution you'd get from using a lower Vdd into a completely moot point: you'd be getting precision that was buried in your margin of error. Again, this is really Tracy's department. I'm interested in whether or not he thinks it's worthwhile.
I'd be inclined to suggest that you go with "it's already good enough", and as I said already, I think that it really is. Still, it's good to be aware of these issues.
Mark in NH said...
You're right, and I also thought about that. So do we need to show the potientiometer voltage to be shown at all?·Right now it's really·good to have it so we can confirm that the CO2 sensor module is working. But does·potientiometer voltage ultimately·need to be shown? The flip side: will it harm anything adversely by keeping it there?
As I mentioned in the previous post, CO2 voltage isn't being written to flash drive as voltage. It's being written as "alarm status"" 1 or 0. Also, when it appears on the screen it's almost directly on top of the other data (temp, humidity, etc.) The temp-humidity-time data stops writing as separate lines of data on the screen, appearing instead as one line of data that changes properly every second. The data does write to the flash drive OK (CO2 as 1's and 0's.) This seems like a simple* task of program reformatting (*simple if you're an electronic engineering genius that is!
You won't ever need the pot voltage. If you have enough program space (variable space) it won't hurt to leave it in there, but I sure wouldn't bother sending it to the flash drive.
How things appear on the screen IS just a matter of formatting, and if you read about the DEBUG commands you should see how to do the formatting you want.
As for sending it to the flash drive, you'll recall that when Tracy set that up with you, he made allowances for eventually changing it from alarm status to the actual voltage. Again, I'll leave the programming advice to him, but it should be pretty straightforward to send the CO2 ppm number...once you've added the code that computes that from the voltages. Tracy was still working with you on figuring those voltages, so we're getting a bit ahead of ourselves.
=======================
Mark in NH said...
So is Chilean Spanish a regional dialect? Or·is 'classic' Spanish spoken and understood in·most South American countries? I thought perhaps that each country spoke a slightly different dialect. But having never been there I can only speculate.
16 teams left, huh? And at least two are from South America I see: Chile and Uruguay. I know this because I'm watching Uruguay beat Korea 1-0 as I eat my French toast (which is 'French' by name only. I have never eaten·French toast·in France. The closest thing is a Croque Monsieur, or crepes. They give me the creeps!)·Did you eat "Spanish toast" for breakfast in Chile...
Chilean Spanish is essentially the Spanish spoken in South America in general, though they do have country-by-country differences. I don't remember the details, but the Nicaraguans have a word for Costa Ricans that is essentially a play on the Costa Rican accent. The main difficulty I've had to adjust to is that they (South Americans) pronouce the double 'L' as "djuh" instead of "yuh". The Chileans had no idea what I was talking about when I said I studied in Sevilla ("say-vee-yuh"), but when I said "Sevilla" ("say-vee-djuh") they understood.
I have had good French toast in Marseille, at a touristy place right down on the old port. I can't honestly say I remember what I had for breakfast in Chile - they fed us and rushed us out to work pretty quickly. But they fed us very well at dinner. I really loved the Chileans and their country. Great place.
Post Edited (sylvie369) : 6/26/2010 4:46:29 PM GMT
I should have added in the post above that in my first comments, I'm simply talking about how to go from the number you receive from the 3202 to a variable representing the number of millivolts input to the 3202. Converting that millivolt value to CO2 ppm is another matter, and one that I expect Tracy will help you with.
===================
I'm having an interesting glitch of my own here, on my GPS tracking project. I bought a small GPS receiver, mounted it on a protoboard with a power supply and an XBee radio, and successfully got it to receive GPS signals and transmit them to my base station, where fix quality, location, altitude, course and speed are all displayed on an LCD. Then I designed a pc board based on the device on the protoboard, and had that manufactured. I mounted the GPS and the XBee, turned it on, and while I'm getting data at the base station, the GPS now takes roughly forever to get a satellite fix, and it's pretty delicate - I easily lose the fix. On top of that, the altitude data never settle into anything reasonable.
With great effort I managed to remove the GPS from the board without breaking it, and remount it on the protoboard, where it works just fine. I'm relieved and mystified.
I'll double-check the board to make sure the connections are the same as on the protoboard. They almost have to be - I do eventually get a lock, and good GPS position data, so my wiring can't be too screwed up. But the GPS just doesn't get a good lock while on the pc board. I'd have thought if anything that it would be the other way around - that all the long wires going all over the place on the protoboard would be more likely to cause problems.
I have some ideas about where the problem might be. First of all, it's possible that I'm trying to draw too much current from the power supply on the board. I've got 4 AA cells going into an LM1117 3.3V regulator, which is supposed to be able to supply 800 mA. The XBee should be drawing about 220 mA, and the GPS about 33 mA, so I should be well under the limit. The regulator does not get hot. This doesn't seem likely to be my problem.
My brother (a TV engineer) suggested I might be getting resonance (?) from the regulator that interferes with the GPS' ability to get a lock. He suggested putting capacitors right on the regulator's leads. I tried that, with no improvement.
Overall, I'd say I've hit a place where just connecting wires together without understanding things like impedance and RF interference has led me into a trap. Of course it's still possible that I've got a bad connection to one of the other GPS pins (there's one that selects between two search modes - I think I have it grounded on both the protoboard and the pc board, but I still have to check). But I suspect the problem has to do with something I don't understand about circuit design when working with RF parts like a GPS receiver. It's a great learning experience.
Another converter for a better resolution sounds great! However, like you said we already have something good enough for our purposes. A better resolution could really help us, but (excuse my arrogance) would that fall under that Occam's razor principle you told me about? About keeping things simple but "good enough"?
Justin,
·· Hello! It's good to see you on the forum. How's· your poison (ivy? oak? sumac?) Is it healing?
You make an excellent point about whether we should factor in Occam's Razor here.·And it·pleases me that you learned what it is and how it applies. I'm not sure whether we should "leave well enough alone" (will the data be accurate enough?) or strive for better resolution (more accuracy in the data, but a more complex ASP_2 with more things that can go wrong.)
Yes, Sir William of Ockham did say, "Simpler is better." But at what cost?
Good point Justin, and not arrogant at all. It is, in fact, germane.·*Word of the day: what does 'germane' mean?
Keep upthe good work and stay active on the forum. As you can see, we're getting closer!
·· Is this a way to get millivoltage to read out as CO2 (ppm)? There's a line of code in the 'MCP_get:' subroutine, the last line below,·that converts the input into millivolts. Couldn't we just look at the 'mV to CO2' graph, calculate the slope-intercept value of the graph line·(-0.0341) and multiply by that value to get ppm?
I tried to write the program command·line to make it multiply by the value I calculated. But it·asked for a·CONstant (or something like that.)
I multiplied:
mVolts0 = result0 */ Cnts2Mv'·*/ -0.0341 but I got a program syntax error (of course.) You·learned that you·can't just multiply the value directly (so do I multiply by DEC? HEX? define a CONstant?) I'm stumped on how to write the code line·but I think I'm in the ball park·re: the·theory behind what to do.
Which brings up the next (actually, previous) point. The inverse correlation between CO2 and mV isn't linear but the·slope-intercept·value I calculated·(-0.0341) was·calculated from the "straight line" part of the·graph··(see attached *Thanks Justin and Tracy!) The ASP-2 may well·descend through·CO2 concentration that is not on the graph line, somewhere between 300 and·400 ppm (345-375 ppm, see second graph) and so wemay have to extrapolate (as Tracy had us do in the graph.)
Do we "curve" the graph line and extrapolate from·a curved line·to calculate·the multiplication factor for converting from mV to ppm? If so, how do you calculate the slope-intercept value for a curved line..? Am I on the right track at all?
I'm having an interesting glitch of my own here, on my GPS tracking project...
...the GPS just doesn't get a good lock while on the pc board.... The regulator does not get hot. This doesn't seem likely to be my problem.
Overall, I'd say I've hit a place where just connecting wires together without understanding things like impedance and RF interference has led me into a trap.
Sylvie, ···· Thanks for all your helpful pointers in your previous post. I agree that we're at a point where we could really use Tracy's programming help....
Your GPS tracking project certainly is ambitious! Like you, things like RF intereference and impedance are waaaaaaaaaaaaaay beyond my skill set. I understand the concepts but I only have a vague (did I mention vague) idea of how someone would go about compensating for them (except maybe RF interference... couldn't you "shield" the device with thin·metal? Maybe?)·My training as an·electrical includes putting batteries in a flashlight and changing a light bulb. That took hours and I had to consult the operator's manual. Twice.
Is the problem that you don't get GPS lock, or that it takes to long to acquire enough satellite signalsto get a good lock? Isn't that typical? When we (used to) geocache it would take 3 or 4 minutes sometimes to get a good GPS lock .I t all seemed to depend on which satellites were programmed into the GPS, where you and they are relative to the horizon, etc. I'm puzzled.
So you designed and then had·a GPS·gizmo manufactured? What does it do? What's it called? Where can we buy one?
Did Uruguay win over Korea? Who plays next? "Who's on first?" (no, who's on third) When does the US play?
Mark
Germane means that it is relevant or appropriate to (in this case) adding another converter.
We still don't know what kind of ivy I have. Fortunately, the medicine is helping to clear it up and dry it out. So many people have some sort of ivy right now!
I'll be checking into the forum again later tonight because I'm going to another graduation party (still!)
Mark in NH said...
Paul and Tracy and Andrew and Rockteers, ·· Is this a way to get millivoltage to read out as CO2 (ppm)? There's a line of code in the 'MCP_get:' subroutine, the last line below,·that converts the input into millivolts. Couldn't we just look at the 'mV to CO2' graph, calculate the slope-intercept value of the graph line·(-0.0341) and multiply by that value to get ppm?
MCP_get: · LOW CS························································· ' Enable ADC · SHIFTOUT DataIn, Clock, MSBFIRST, [noparse][[/noparse]%1101\4]·····' Select CH0, Single-Ended · SHIFTIN DataOut, Clock, MSBPOST, [noparse][[/noparse]result0\12]···· ' Read ADC · HIGH CS··························································' Disable ADC ·mVolts0 = result0 */ Cnts2Mv···························· ' Convert To Millivolts
I tried to write the program command·line to make it multiply by the value I calculated. But it·asked for a·CONstant (or something like that.)
I multiplied: mVolts0 = result0 */ Cnts2Mv'·*/ -0.0341 but I got a program syntax error (of course.) You·learned that you·can't just multiply the value directly (so do I multiply by DEC? HEX? define a CONstant?) I'm stumped on how to write the code line·but I think I'm in the ball park·re: the·theory behind what to do
Look at the top of the code (this from the sample code for the 3202:
' -----[noparse][[/noparse] Program Description ]---------------------------------------------
' This demo uses the wipers on 2 10K Ohm pots to provide an analog voltage
' for channel 0 and 1 on the ADC; then displays the voltage and 12-bit value
' for each channel on the DEBUG terminal. Using a 5 VDC reference the 12-bit
' values should be roughly 0 TO 4096 and the voltage from 0 to 5
' -----[noparse][[/noparse] Revision History ]------------------------------------------------
' N/A
' -----[noparse][[/noparse] I/O Definitions ]-------------------------------------------------
CS PIN 0 ' Chip Select (MCP3202.1)
Clock PIN 1 ' Clock (MCP3202.7)
DataOut PIN 2 ' Pin 6 on ADC (MCP3202.6)
DataIn PIN 3 ' Pin 5 on ADC (MCP3202.5)
' -----[noparse][[/noparse] Constants ]-------------------------------------------------------
Cnts2Mv CON $0139 ' x 1.22 (To Millivolts)
The Basic Stamp only knows about integers, and only about positive numbers, for that matter. You can't declare anything to be -0.0341 - that's completely Greek, as it were, to the Stamp. Notice that the sample program uses $0139 to represent +1.22. Tracy will explain how you find the number you're going to use (<--- this is known as "passing the buck"), but it's going to look something like this.
As far as dealing with a curve instead of a straight line, curves have simple equations as well. They're not linear, of course, so it's not just y = mx + b: there IS no "slope-intercept" form. There'll be another term, with x raised to some power (2, in your case, probably). Now you might have a good enough fit to a line that you don't need to bother with that. Or you might discover that it's not simply y = ax2 + bx + c, but rather is better fit by some other kind of function. Whichever it turns out to be, you just have to find the equation, and then the way of getting the Stamp to do the integer math equivalent of that equation. But of course that's all Tracy's department. <grin>
===================
I might wind up having to shield something on the GPS gizmo, but I don't think that's the problem, as it works (unshielded) on a protoboard. I think the problem has to do with how signals and power are carried on the pc board's traces, but again, this is all beyond me as well. I'll be out hat in hand looking for advice when I get a chance.
The GPS takes forever (20 minutes?) to get a valid signal, and loses that signal frequently, without ever locking again. That's unacceptable in a rocket tracker, of course. But again, on the protoboard it's up to a valid signal and 10 satellites inside of a minute or two after power up, and regains signal readily.
I only had the pc board manufactured, and there's no device for sale. If I get it working, I'll distribute a few to fellow rocketeers for more varied testing, and eventually consider selling the boards at a little over cost. I have no intention of going commercial - I don't have time or interest in supporting a product.
==============
The U.S. is down 0-1 to Ghana at the half. If we don't come back, we're out. The rest is single elimination.
The Basic Stamp only knows about integers, and only about positive numbers, for that matter. You can't declare anything to be -0.0341... the sample program uses $0139 to represent +1.22.
You read my mind Paul...! You knew what I was tinkering with in the program code
1)·Why, or how·does the·constant·"Cnts2Mv"·equal the number·1.22 ?
Cnts2Mv CON···· $0139···· ' x 1.22 (To Millivolts)
How would you make a hypothetical·CONstant "Cnts2ppm" (converts to ppm) equal 0.0341?
Cnts2ppm CON···· $ ????·····' x·-0.0341 (To parts per million)
What about negative -0.0341?
DONOVANSCORES............! Ghana with the corner kick. Looks like·the game might·go into a shoot-out.
UGH. Ghana just scored... at 92:55 in extra time. Game over. Very much over.· ·
I was very busy last week and had to tune out here, sorry. Actually, yes, it is good for you to figure things out by trial and error! Today I'm at the Propeller expo (UPEW) at Parallax headquarters. There is lots of energy here, and projects on display, and a couple of teachers are interested in doing rocketry projects with their students. Maybe they will chime in here.
One nice thing is that the kind folks at Parallax gave me a CO2 sensor and an MCP3202 so that I can try it out myself and follow along more closely with your progress and maybe give you better advice. I have some ideas about how to stretch out the resolution to give better resolution at the low end. I'll try it myself first though, before I really really suggest anything that voids your warranty!
Mark, the fact that data fields appear on a separate line is probably an artifact of your computer terminal (the debug screen). If the data line is too long, it wraps it down to the next line. Does that make sense in view of what you are seeing?
If you want the mV from the CO2 sensor to appear in the USB thumb drive file, you have to say,
mVolts0 = result0 */ Cnts2Mv ' Convert To Millivolts
CO2pp = mVolts0 ' <---- this variable CO2pp goes onto the flash drive
That is because the program as written is logging the variable called CO2pp to the thumb drive, and right now that value is the 0 or 1 alarm status. Also, you have to comment out the line that reads the alarm status.
About */ Cnts2Mv, where Cnts2/Mv=$0139. I don't like to write it as a hex number. I just write it as decimal, $0139=313 in decimal. What do you get when you divide 313/256? 1.22265625. That is pretty close to the multiplier 1.2207 that we need to convert counts to millivolts. That is the way the BASIC stamp does fractions. Internally, when the Stamps comes across this expression,
mVolts0 = result0 */ 313 ' 313 is the same as $0139 is the value of the constant, Cnts2Mv
it multiplies result0 times 313 and then divides that by 256.
The graph shows that the mV output of the sensor is inversely proportional NOT to CO2 ppm directly, but to the logarithm of CO2 concentration. Even with that in mind, it is not exactly a straight line and curves around at low levels. It is hard to tell from that graph what to expect at lower CO2 concentrations. That is part of why we were talking about interpolation vs extrapolation.
@ Paul, the problem with the GPS may be due to what is near it on the circuit board. If circuit board traces run under or even near the antenna, they can create interference patterns in the radio waves that it depends on.
·What do you get when you divide 313/256? 1.22265625. That is pretty close to the multiplier 1.2207 that we need to convert counts to millivolts.
Dr.Allen,
It sounds to me·that you are saying that 1.22265625 goes to 1.2207. Is this correct? If so, how does the STAMP go from 1.22265625 to 1.2207? If you rounded it, wouldn't the outcome be 1.223?
· The Parallax/Propeller symposium sounds interesting. Was it a day-long event? What all did you do and see there? Did a lot of people attend? Did you present? I'd love the opportunity to come out and see the whole Parallax operation·some time. I'm glad you got a CO2 sensor and an ADC chip (if·I had known you didn't have them we would have sent you some.) How far is Parallax from where you are?
Thanks for posting the code to make the CO2 sensor's millivoltage show up on the flash drive.·The mV shows up on the flash drive now. Plus, adding this new·code confirmed·something that we thought was happening (or rather, wasn't happening): the mV·that indicatesCO2·fluctuation does NOT change at all when pure CO2 is applied to the sensor.
Chris and I·back-tracked to page 8 of this forum and we re-built the CO2 sensor "test stand"·on·a separate·BOE protoboard. We wanted to·double-check that the sensor itself was working. However, when we wired the·third BOE and ran the page 8 code (below)·the same thing happens as above: there is no mV fluctuation when pure CO2 is applied to the sensor. Voltage drops and stays at '0' at TP1 - TP2.
From page 8:
1) Connect voltmeter between TP1 and TP2 - Check
2)·Connect Vin to Vin on BOE - Check
3) Connect 'Com' (GND)·to Vss on BOE - Check
4) Connect CNTL to p4 on·the Stamp·with a 1000 Ohm resistor between p4 and CNTL - Check
5) Connect the ALR· to pin p3,· also via a 1000 Ohm resistor - Check
6) Run program below. Now observe the voltmeter connected between TP1 and TP2·- NO VOLTAGE CHANGE when pure CO2 is applied. Voltage drops to '0'·at TP1 - TP2 and stays there.
HIGH 4 ' turn on the heater.
DO
DEBUG BIN1 IN3 ' display the alarm status
LOOP
After 3-1/2 hours of troubleshooting the problem from every angle we know (and after considering a walk to the garage to get a sledgehammer for 'the ultimate fix'), we made a discovery. When·you connect the wire from the CO2 sensor's 'Vin'·pin to·the proto-BOE's·'Vdd' pin (NOT Vin-to-Vin), mV does fluctuate at TP1 and TP2 when·pure CO2 is applied.
We·tried the same fix on the ASP-BOE-CO (switched the input wire to Vdd instead of Vin) without success. We tried (somewhat randomly, because we'd been at it for hours, and we were hungry) switching a few other Vss/Vdd/Vin wires to the ASP-BOE back and forth without success.
Conclusions:
1) The mV representing CO2 on the ASP-BOE does NOT represent CO2 fluctuation (it didn't change at all when pure CO2 was applied.) As it's wired now, millivoltage at TP1 - TP2 drops·to and then remains near '0'.
2) The same thing occured when the 'CO2 test stand" was wired Vin-to-Vin. Wiring it Vin-to-Vdd·seemed to fix the problem.
3) We suspect the breadboard is currently wired incorrectly. Attached is a wiring schematic for the stand-alone breadboard wiring. I will hide the sledgehammer for now.
Tracy and Sylvie, Andrew and Rocketeers, friends, Romans, and countrymen·- Would you mind looking at the attached wiring schematic and see if you can locate the wiring (?) gremlin that's causing the CO2 sensor not to show a millivoltage change? If that's not it, then what? The sledgehammer...?
I'm a bit surprised to see that you have TP1 from the sensor wired to channel 1 (rather than channel 0) on the 3202. It will work that way, but you need to be aware that the CO2 level will be coming through that channel. Make sure that's the one you're reading in your software. You have (according to the wiring diagram) the output of the CO2 sensor's potentiometer wired to channel 0, so if your software is reading only that channel, you will only see variations when you adjust that pot.
I'm not sure why you have 1K resistors going from the sensor's TP1 and TP3 to the 3202's input pins. Tracy may have suggested that and I just missed it: I wouldn't have used them, myself. In addition, if your diagram is meant to represent how things are placed on a protoboard, those resistors don't seem to be doing anything. Every pin in a row of a protoboard is connected to every other pin in that row, so if both ends of the resistors are in the same row, it's just spare parts, essentially (I guess it would amount to a resistor wired in parallel with a wire, but that's essentially a 0K resistor). Now, I'm not sure you mean the diagram to be read that literally - it has something similar for the resistor on the Din and Dout pins, but I don't think that's what you have there.
Do you know the difference between Vin and Vdd? On the BoE, Vdd will be 5V (or something very close to that). Vin will be whatever voltage you're feeding TO the BoE from your battery. The CO2 sensor's Vin pin is supposed to require 6.5V to 12V, so Vdd should _not_ work (which is, of course, the opposite of what you're reporting here). It needs more than 6V because it supplied 6V to the heater circuit to get that to work properly.
When you're making your measurements, is the heater circuit on? I suspect that's determined by your software - it depends on where the CNTL pin of the CO2 sensor is connected. If it's not connected, that's your problem. If it's connected to one of the BoE i/o pins, that pin needs to be programmed to turn on the circuit. Tracy will help you determine that part (as, again, I'm going to try to avoid messing with your code).
·What do you get when you divide 313/256? 1.22265625. That is pretty close to the multiplier 1.2207 that we need to convert counts to millivolts.
Dr.Allen,
It sounds to me·that you are saying that 1.22265625 goes to 1.2207. Is this correct? If so, how does the STAMP go from 1.22265625 to 1.2207? If you rounded it, wouldn't the outcome be 1.223?
Sean
Sean -
Because the Basic Stamp only does integer math, you have to use this kind of trick to represent fractions. 313/256 is as close as you're going to get to 1.2207, and it's close enough: your error is in thousandths of millivolts (that is, less than millionths of a volt), and the hardware itself introduces bigger errors than that. If you were to pick the next number down to try to get closer, you'd have 312/256 = 1.21875, which is just about exactly the same error, but on the other side. It won't help you any. And you can't use 312.5/256 (which would give you almost exactly 1.2207), because 312.5 is not an integer, and so the Stamp can't use it. You could do some tricks, but they'd come at a cost, and again, the error is so small that it wouldn't gain you anything.
Tracy -
I don't want to hijack things here with trouble-shooting about my GPS board, but I will·probably post a question about it to the Sandbox sometime in the next couple of days·if I don't find a wiring issue that fixes it. I did run wires·from the GPS module to the pc·board's GPS connections, separating the module from the traces,·without any improvement.
You have... the output of the CO2 sensor's potentiometer wired to channel 0, so if your software is reading only that channel, you will only see variations when you adjust that pot.
Yes, the potientiometer IS wired through channel 0. When I·wired it through channel 1 a few days agi the voltage dances all·around and could not·be adjusted or stabilized with the potentiometer. That seems diagnostic but I'm not sure how to use it diagnostically... part of the problem and part of the solution I suppose (along with the 'hammer.)
sylvie said...
I'm not sure why you have 1K resistors going from the sensor's TP1 and TP3 to the 3202's input pins. Tracy may have suggested that...
I think Tracy suggested resistors for CH0 and CH1 a few pages back-- which is why they're there-- but I'll go back and check again just to be sure.
The resistors·are "in-line"; that is, they're in the same "row" as the CH0 and CH1 ADC pins (between the ADC pin and the wire to the BOE.) The picture may be misleading (oops!)
I removed both resistors, ran the program again, and got the same results (oops!)
sylvie said...
Do you know the difference between Vin and Vdd?
Yes, Vdd is regulated to 5 volts, right? And Vin is "full, direct voltage" (e.g. if the source is 9.2 v, you get 9.2 v if the wire is connected to Vin. Yes?
With that said, so why does the sample code run the CO2 test set-up OK with Vdd and not with Vin (which is how it's "supposed" to be wired. I'm getting up to my ears in alligators and my head is swirling around...!
sylvie said...
When you're making your measurements, is the heater circuit on?
The program code indicates that the·heater (CNTL/HSW) is turned on so I'm assuming it is.
Stumped,
Mark
I saw Argentina crushing Mexico 3-0 a little while ago. And the US sure lost a heartbreaker, didn't they? I couldn't believe·it when·Ghana scored so late in the game (and I can't believe I'm actually watching soccer!) Not long ago it was not on my 'top 10' list of fun things to do. My how things change!
The wiring diagram is accurate. The CH0 and CH1 resistors are oriented correctly in the diagram. There is also a "jump" resistor that connects the Din and Dout ADC pins. It's perpendicular to the CH0 and CH1 resistors on the breadboard.
Mark in NH said...
The wiring diagram is accurate. The CH0 and CH1 resistors are oriented correctly in the diagram. There is also a "jump" resistor that connects the Din and Dout ADC pins. It's perpendicular to the CH0 and CH1 resistors on the breadboard.
If both leads of a resistor are in the same row on the protoboard then the resistor is not doing anything. Remember that all of the holes in a row on a protoboard are connected together. It sounds to me as though you're saying that·you have a row that has this: (got my fingers crossed that this will work...).
·················
/\/\/\/
====
|
|
=====
3202 pin --- 1 resistor lead --- other resistor lead --- wire going to BS2 on BoE
If that's the case, then the resistor is doing nothing. If you want a resistor in series with the connection from a 3202 pin to a BS2 pin, you need to have one lead of the resistor in the protoboard row with the 3202 pin, and the other lead in a completely separate row, with the wire going out to the BS2 in that second row as well.
Sorry if I'm misunderstanding things and you already knew this.
The sole purpose of the resistor is to act as protection for the ADC input in the unlikely event that someone connects that pin to Vin by mistake. Let's says someone is in a hurry and the wire slips. That would be bad! Other than that the resistor serves no purpose in the operation of the circuit.
In general in electronics, it is wise to include some sort of protection in wires that go "off-board". A resistor is the first line of defense as it limits current to a safe level.
Tracy Allen said...
The sole purpose of the resistor is to act as protection for the ADC input in the unlikely event that someone connects that pin to Vin by mistake. Let's says someone is in a hurry and the wire slips. That would be bad! Other than that the resistor serves no purpose in the operation of the circuit.
In general in electronics, it is wise to include some sort of protection in wires that go "off-board". A resistor is the first line of defense as it limits current to a safe level.
I see. Yup, that makes sense.
Still, if the resistor is connected the way it sounds like it's connected, it's not meeting that purpose - the excessive current would simply bypass the resistor and run right in through the protoboard's connection. Right?
··We connected the resistors and wires the way Sylvie suggested. We also ran the program without and resistors. Finally, we put the resistors back·like I had them originally (see diagram·above.) The results were the same in all three configurations: voltage could be·adjusted·with the potientiometer but the CO2 sensor/voltage was unresponsive·(showed no fluctuation at all when pure CO2 was applied.)
Tracy, we'll install a new ADC chip "just in case" we cooked the one currently·on the board when we were fiddling with the wires (or as you said, "...in the unlikely event that someone connect(ed) that pin to Vin by mistake." By mistake? Who...US?! The likelihood of that happening is about as likely as Ghana·beating the US soccer team in the World Cup.)
Attached are three pictures of the ADC breadboard wiring and·resistors to better explain where they're located and how they're oriented. They go·with the black-and-white schematic several posts back.
The sole purpose of the resistor is to act as protection... In general in electronics, it is wise to include some sort of protection in wires that go "off-board".
Is 1 K ohm resistor·"standard"? Why not use, say, a 500 ohm or 200 ohm resistor? What determines which size resistor to use? ·
The value of the resistor is not critical. Anything in the neighborhood of 500 to 2000Ohms will work. Lower values=not as much protection; higher values, more chance of electrical noise pickup.
Your wiring photo looks good. Checking here. You do have Vss connected to Vss on the module, right?
Do you have a multimeter that lets you measure what is coming out on TP1 and to compare that with what is going in to ch0 on the ADC?
Please post the code you are using for this test, and a photo that shows how you have it hooked up to the CO2 sensor. I have the ADC hooked up here, but not yet the CO2. The ADC seems to be working fine.
Here is my diagram taken from an earlier one you posted:
Comments
Thanks for rattling my brains around, Paul! And thanks for holding off and lettingme figure this one out, Tracy. You guys are great. Paul, your last post caused me to approach the dilemma from a different angle and the fly in the ointment was (lo and behold) misnamed/misplaced wires, not an error in the program.·Andrew, it·seem that·your (and Dr. Allen's) "mash-up" program WORKS!·(*better hire him or get him a scholarship Tracy, before he gets an offer from MIT. He'd do well at Berkeley or Cal-Tech.)
Paul, when you mentioned that the pin numbers were different·("...referring to pin 14, which I believe you have been connecting to 3202's clk, which is·pin 7")··I went back and·compared which pin·each wire went to versus·what it said in the (attached) program.·And there the problem was. Three wires were going to the wrong pins!
As soon as I moved the three wires to match the I/O definitions in the program, "good" numbers appeared (voltages below 3.1, etc.) To confirm that it was working I did as Tracy suggested: I dialed the potientiometer screw clockwise and counterclockwise and watched the voltage (and its corresponding number) increase and decrease. I also blew "pure" CO2 into the sensor (from an aerosol·CO2 cartridge) and the other set of numbers responded accordingly. I'm giddy (my wife thinks I'm goofy most of the time so she can't tell.)
Soooooooooooooooooooo.!
I'll post the wiring scheme that goes with the attached program so Andrew and the other Rocketeers can build their ASP-clones at home and run·them with a good degree of confidence that·they will work. I'm headed back into the "lab" (the dining room table) to tinker with the ASP-clone, the wires, and the program a bit more. I believe we've·crossed a·big hurdle together.
Thanks guys! More later.
Mark
A comment: if you're trying to read an analog pin and your readings are all 0, 255, 512, 4096 and so on (that is, powers of 2, or one less), there's something wrong with your wiring, probably. It could be the programming. It's very likely NOT legitimate voltage readings.
Spain wins, and both Spain and Chile move on. I'm rooting for Spain.
Attached is a "cleaner", easier to read, more professional looking version of the same program I just posted,which works pretty well. I will upload the wire·schematic so you can·finish building your·ASP-clone at home.
Please download·the program·and·examine it closely to see how we can make·the program·work even better. Andrew, please facilitate the discussion and explain to your new teammates any changes you propose, and why.
Pros:
1) "Adjustment voltage" (and its accompanying numbers) reads out to the computer screen and·changes·when the CO2 sensor's potientiometer is adjusted.
2) "CO2 voltage" and its number also appear on the computer screen. CO2 millivoltage is low-- from about 0.05 to 0.250 +/-·mV (as expected with low ambient·CO2 concentration).
3) The MAWDBOE data (sample number, elasped time, temperature, humidity, and altitude) appear on the screen·in columns and are written to the flash drivejust fine.
Cons:
1) The CO2 "number" correlated with voltage increases when voltage increases. Shouldn't it decrease? (since the relationship between millivoltage and CO2 concentration is inverse, according to the graph in the documentation.) I'm not sure whether CO2 is really being measured...
2) The COs voltages and numbers appear right on top of the MAWDBOE data on the computer screen.
3) When the data is downloaded from the flash drive it is still binary (1's and 0's, not voltage/numbers.)
4) When the CO2 voltages and numbers appear on the screen,·the MAWDBOE data stops writing data·in columns on the screen. It's still·visible·but·it appears as one line of data only, and it's offset.·The data·still change as·they should and it still writes data·in columns to the flash drive.
Rocketeers, please offer your suggestions on how we can remedy these 'cons'. Download·the program·and look at it closely, and...
Enjoy the weekend!
Mr. (Mark) Kibler, Rocketeer.
Yes, I wondered why the (previous) voltages were all powers of 2 (high voltage was 4095(6) and·low voltage was 255(6)... exactly 1/16 of 4096. But I didn't want to ask such a 'simple' question. I wondered if it might indicate something like bad wiring... now you tell me!
So we roll into the weekend with that little bump smoothed over. It seems like such a big step though!. I just posted some pros and cons about the program, seemingly small things by comparison.
Andrew did a really good job of putting together the "mash-up" program from the various subroutines Tracy uploaded, don't you think?·I'm very pleased that it works so well. I was expecting at least a few more weeks of troubleshooting (knock on wood.)
I looked at the "CO2 concentration versus millivoltage" graph again and the inverse linear relationship between the two isn't quite linear. The graph line curves upward as mV increases and CO2 concentration decreases·on the left side of the graph. Now I understand why Tracy asked the Rocketeers about this a few weeks ago. How will we adjust for·a non-linear relationship in·the algorithm·in the program?·Ambient CO2 is relatively low, roughly 100-350 ppm. That CO2 concentration is off the graph line. Tracy knew weeks ago that we would need to know this weeks later. It's like he can see into the future! You and Tracy are geniuses. I am·honored just to walk in your shadows...
Any fun plans·for the weekend? I have yard work and house work to do, then we'll probably go for a jog or a hike or a bike ride at the state park at the end of our road. Don't stay up too late in cyber space! Vive Espana! Go Chile!
Mark
Voltage on 3202's input pin --> Converted by 3202 to a unitless number from 0 to 4096 and sent to BoE --> Converted by your program to a voltage (units: volts or millivolts)·--> Converted by your program (eventually) to·CO2 level (units: ppm)
It's only on that last step that the inverse relationship will make a difference, and you will have to program it to take care of that. But the number from the 3202 will always have a positive correlation with the voltage on the 3202 input pin.
You wrote "CO2 millivoltage is low-- from about 0.05 to 0.250 +/-·mV (as expected with low ambient·CO2 concentration)."
You can see then why I was talking a couple of screens back about trying to make better use of your ADC's range. It can measure from 0 to 5 volts, but you're only encountering 0 to .25 volts, so more than 90% of your range is unused with this sensor. Again, that's not the end of the world, but if there were an easy way to make that 0-4096 represent (say) 0·to .5 volts, you'd have MUCH better resolution.
Another important comment: In your real application, you're not going to care about the setting of the potentiometer mounted on the CO2 sensor. It's only there to change the alarm setting, and you're not using the alarm, you're reading CO2 level directly from TP1. It's good that you're able to read that setting also, but there's no need for it in your program: it doesn't tell you anything about the outside world. It only tells you where you've left the onboard pot set.
En Chile se habla Espanol. Hay 16 equipos en el segundo parte del World Cup. Se puede verlos aqui:
http://www.fifa.com/worldcup/matches/index.html
sylvie 369 said...
Do you mean the number ranging from 0 to 4096 that comes from the 3202? That number SHOULD increase with the voltage.
Yes, the number from 0 to 4096 was the number I was referring to. So·showing it as·an inverse relationship is done in the programming then?·I just looked at the program and now I see·that there's an equation·to convert the·"numbers" into voltage: "mVolts0 = result0 */ Cnts2Mv". 'Result0' must be the number and '/Cnts2mv'·must mean 'converts to milllivolts' (or functions to do that.) Converting·from 0 - 4096 to·CO2 ppm is done·in a similar way then, with a forumla in the program. I think I get it.
You wrote "CO2 millivoltage is low-- from about 0.05 to 0.250 +/-·mV (as expected with low ambient·CO2 concentration).
Yes, that's correct. The·CO2 re"ading is between 0.05 and 0.250 +/- volts. If the maximum voltage·is 3.0 volts,·then the CO2 reading·is relatively low at 0.05 to 0.250. But I'll confirm the·reading later just to be sure.
You can see then why I was talking a couple of screens back about trying to make better use of your ADC's range... more than 90% of your range is unused with this sensor.·
Yes, that makes much more sense now. If the maximum possible voltage is 3.0+ volts and the maximum reading (currently...no pun intended) is 0.25 volts, then the range from 0.25 to 3.0 is, as you said, unused.
...if there were an easy way to make that 0-4096 represent (say) 0·to .5 volts, you'd have MUCH better resolution.
Yes, this makes sense too. The questions are, "How do you make 0 to 4096 represent 0.5 volts? How do you increase the resolution?" I recall a few pages back that Tracy said it·would require another converter (or something similar)... more electronics, more wires, more programming. I think we weighed the options between adding another converter or keeping what we haveas "good enough for our purposes." I'll re-read the conversation again but I think that was the gist of it.
So what are the options for better data resolution? I see three options·(but I wear glasses): 1) Add another converter as I just explained, or 2)·Adjust for·better resoultion in the program/algorithm. I'm not if sure that's a viable option. That's where I defer to you and Tracy. 3) Keep things 'as is', run the program, and see what we get for data/resolution. Then reconsider options #1 and #2 if need be.
...you're not going to care about the setting of the potentiometer mounted on the CO2 sensor. It's only there to change the alarm setting... there's no need for it in your program: it doesn't tell you anything about the outside world. It only tells you where you've left the onboard pot set.
You're right, and I also thought about that. So do we need to show the potientiometer voltage to be shown at all?·Right now it's really·good to have it so we can confirm that the CO2 sensor module is working. But does·potientiometer voltage ultimately·need to be shown? The flip side: will it harm anything adversely by keeping it there?
As I mentioned in the previous post, CO2 voltage isn't being written to flash drive as voltage. It's being written as "alarm status"" 1 or 0. Also, when it appears on the screen it's almost directly on top of the other data (temp, humidity, etc.) The temp-humidity-time data stops writing as separate lines of data on the screen, appearing instead as one line of data that changes properly every second. The data does write to the flash drive OK (CO2 as 1's and 0's.) This seems like a simple* task of program reformatting (*simple if you're an electronic engineering genius that is!)
Where do we go from here, now that the CO2 sensor reads out voltage? What do you see as the next step(s) in the project?
So is Chilean Spanish a regional dialect? Or·is 'classic' Spanish spoken and understood in·most South American countries? I thought perhaps that each country spoke a slightly different dialect. But having never been there I can only speculate.
16 teams left, huh? And at least two are from South America I see: Chile and Uruguay. I know this because I'm watching Uruguay beat Korea 1-0 as I eat my French toast (which is 'French' by name only. I have never eaten·French toast·in France. The closest thing is a Croque Monsieur, or crepes. They give me the creeps!)·Did you eat "Spanish toast" for breakfast in Chile...?
Good morning,
Mark
Another converter for a better resolution sounds great! However, like you said we already have something good enough for our purposes. A better resolution could really help us, but (excuse my arrogance) would that fall under that Occam's razor principle you told me about? About keeping things simple but "good enough"?
Justin
If you have a reading of 2048, you're halfway through the 5000 mV scale, and you should be able to see intuitively that the voltage is 2500 mV (2.5 volts), right? Using the equation instead of intuition, you have
mV = (2048/4096)*5000··· <--- in other words, (how far through the scale you are) * (how long the scale is).
Actually the range is from 0 to 5 volts, or whatever voltage you're using to power the 3202. The 3202 chip doesn't know about the maximum voltage the sensor could put out. It allocates the number (0..4095) to a range from 0 volts to whatever voltage is applied to its Vdd pin (again, in your case, 5 volts).
The range that the 3202 divvies up the numbers over is determined by the voltage on its Vdd pin, so using a lower voltage there will give you more resolution. But there are two caveats: first, you have to give the 3202 enough voltage to work. If I remember correctly, it requires at least 2.7 V. Secondly, you would probably need to worry about the levels of the three data lines connecting the 3202 to the BoE. I think that's a killer, probably - complicated enough to make this not worth doing. But Tracy may know a simple way to do it (or even perhaps that it doesn't need to be done - that the BoE can read logic levels from a chip powered by 2.7 V).
There's also a chance you'd just be getting false resolution. As I said, the reference voltage is the voltage applied to the 3202's Vdd pin, and I've said a number of times that it's 5 V. But it's probably actually a few tens of millivolts higher than that. When I set mine up, the 5 V supply I used actually gave the 3202 5.06 volts, and so the true reading on the input pin would have been
mV = (number/4096) * 5060·· <--- not " * 5000 "
You could measure the actual input voltage and use that in your equation, and improve the accuracy a bit. Or you could just pretend that it's really 5V. Either way, it may wander a bit (this is what the capacitor is designed to minimize), and the wandering it does may be enough to make the increased resolution you'd get from using a lower Vdd into a completely moot point: you'd be getting precision that was buried in your margin of error. Again, this is really Tracy's department. I'm interested in whether or not he thinks it's worthwhile.
I'd be inclined to suggest that you go with "it's already good enough", and as I said already, I think that it really is. Still, it's good to be aware of these issues.
You won't ever need the pot voltage. If you have enough program space (variable space) it won't hurt to leave it in there, but I sure wouldn't bother sending it to the flash drive.
How things appear on the screen IS just a matter of formatting, and if you read about the DEBUG commands you should see how to do the formatting you want.
As for sending it to the flash drive, you'll recall that when Tracy set that up with you, he made allowances for eventually changing it from alarm status to the actual voltage. Again, I'll leave the programming advice to him, but it should be pretty straightforward to send the CO2 ppm number...once you've added the code that computes that from the voltages. Tracy was still working with you on figuring those voltages, so we're getting a bit ahead of ourselves.
=======================
Chilean Spanish is essentially the Spanish spoken in South America in general, though they do have country-by-country differences. I don't remember the details, but the Nicaraguans have a word for Costa Ricans that is essentially a play on the Costa Rican accent. The main difficulty I've had to adjust to is that they (South Americans) pronouce the double 'L' as "djuh" instead of "yuh". The Chileans had no idea what I was talking about when I said I studied in Sevilla ("say-vee-yuh"), but when I said "Sevilla" ("say-vee-djuh") they understood.
I have had good French toast in Marseille, at a touristy place right down on the old port. I can't honestly say I remember what I had for breakfast in Chile - they fed us and rushed us out to work pretty quickly. But they fed us very well at dinner. I really loved the Chileans and their country. Great place.
Post Edited (sylvie369) : 6/26/2010 4:46:29 PM GMT
===================
I'm having an interesting glitch of my own here, on my GPS tracking project. I bought a small GPS receiver, mounted it on a protoboard with a power supply and an XBee radio, and successfully got it to receive GPS signals and transmit them to my base station, where fix quality, location, altitude, course and speed are all displayed on an LCD. Then I designed a pc board based on the device on the protoboard, and had that manufactured. I mounted the GPS and the XBee, turned it on, and while I'm getting data at the base station, the GPS now takes roughly forever to get a satellite fix, and it's pretty delicate - I easily lose the fix. On top of that, the altitude data never settle into anything reasonable.
With great effort I managed to remove the GPS from the board without breaking it, and remount it on the protoboard, where it works just fine. I'm relieved and mystified.
I'll double-check the board to make sure the connections are the same as on the protoboard. They almost have to be - I do eventually get a lock, and good GPS position data, so my wiring can't be too screwed up. But the GPS just doesn't get a good lock while on the pc board. I'd have thought if anything that it would be the other way around - that all the long wires going all over the place on the protoboard would be more likely to cause problems.
I have some ideas about where the problem might be. First of all, it's possible that I'm trying to draw too much current from the power supply on the board. I've got 4 AA cells going into an LM1117 3.3V regulator, which is supposed to be able to supply 800 mA. The XBee should be drawing about 220 mA, and the GPS about 33 mA, so I should be well under the limit. The regulator does not get hot. This doesn't seem likely to be my problem.
My brother (a TV engineer) suggested I might be getting resonance (?) from the regulator that interferes with the GPS' ability to get a lock. He suggested putting capacitors right on the regulator's leads. I tried that, with no improvement.
Overall, I'd say I've hit a place where just connecting wires together without understanding things like impedance and RF interference has led me into a trap. Of course it's still possible that I've got a bad connection to one of the other GPS pins (there's one that selects between two search modes - I think I have it grounded on both the protoboard and the pc board, but I still have to check). But I suspect the problem has to do with something I don't understand about circuit design when working with RF parts like a GPS receiver. It's a great learning experience.
·· Hello! It's good to see you on the forum. How's· your poison (ivy? oak? sumac?) Is it healing?
You make an excellent point about whether we should factor in Occam's Razor here.·And it·pleases me that you learned what it is and how it applies. I'm not sure whether we should "leave well enough alone" (will the data be accurate enough?) or strive for better resolution (more accuracy in the data, but a more complex ASP_2 with more things that can go wrong.)
Yes, Sir William of Ockham did say, "Simpler is better." But at what cost?
Good point Justin, and not arrogant at all. It is, in fact, germane.·*Word of the day: what does 'germane' mean?
Keep upthe good work and stay active on the forum. As you can see, we're getting closer!
Mr. Kibler
·· Is this a way to get millivoltage to read out as CO2 (ppm)? There's a line of code in the 'MCP_get:' subroutine, the last line below,·that converts the input into millivolts. Couldn't we just look at the 'mV to CO2' graph, calculate the slope-intercept value of the graph line·(-0.0341) and multiply by that value to get ppm?
MCP_get:
· LOW CS························································· ' Enable ADC
· SHIFTOUT DataIn, Clock, MSBFIRST, [noparse][[/noparse]%1101\4]·····' Select CH0, Single-Ended
· SHIFTIN DataOut, Clock, MSBPOST, [noparse][[/noparse]result0\12]···· ' Read ADC
· HIGH CS··························································' Disable ADC
· mVolts0 = result0 */ Cnts2Mv···························· ' Convert To Millivolts
I tried to write the program command·line to make it multiply by the value I calculated. But it·asked for a·CONstant (or something like that.)
I multiplied:
mVolts0 = result0 */ Cnts2Mv'·*/ -0.0341 but I got a program syntax error (of course.) You·learned that you·can't just multiply the value directly (so do I multiply by DEC? HEX? define a CONstant?) I'm stumped on how to write the code line·but I think I'm in the ball park·re: the·theory behind what to do.
Which brings up the next (actually, previous) point. The inverse correlation between CO2 and mV isn't linear but the·slope-intercept·value I calculated·(-0.0341) was·calculated from the "straight line" part of the·graph··(see attached *Thanks Justin and Tracy!) The ASP-2 may well·descend through·CO2 concentration that is not on the graph line, somewhere between 300 and·400 ppm (345-375 ppm, see second graph) and so wemay have to extrapolate (as Tracy had us do in the graph.)
Do we "curve" the graph line and extrapolate from·a curved line·to calculate·the multiplication factor for converting from mV to ppm? If so, how do you calculate the slope-intercept value for a curved line..? Am I on the right track at all?
Mark
···· Thanks for all your helpful pointers in your previous post. I agree that we're at a point where we could really use Tracy's programming help....
Your GPS tracking project certainly is ambitious! Like you, things like RF intereference and impedance are waaaaaaaaaaaaaay beyond my skill set. I understand the concepts but I only have a vague (did I mention vague) idea of how someone would go about compensating for them (except maybe RF interference... couldn't you "shield" the device with thin·metal? Maybe?)·My training as an·electrical includes putting batteries in a flashlight and changing a light bulb. That took hours and I had to consult the operator's manual. Twice.
Is the problem that you don't get GPS lock, or that it takes to long to acquire enough satellite signalsto get a good lock? Isn't that typical? When we (used to) geocache it would take 3 or 4 minutes sometimes to get a good GPS lock .I t all seemed to depend on which satellites were programmed into the GPS, where you and they are relative to the horizon, etc. I'm puzzled.
So you designed and then had·a GPS·gizmo manufactured? What does it do? What's it called? Where can we buy one?
Did Uruguay win over Korea? Who plays next? "Who's on first?" (no, who's on third) When does the US play?
Mark
Germane means that it is relevant or appropriate to (in this case) adding another converter.
We still don't know what kind of ivy I have. Fortunately, the medicine is helping to clear it up and dry it out. So many people have some sort of ivy right now!
I'll be checking into the forum again later tonight because I'm going to another graduation party (still!)
Checking in later,
Justin
The Basic Stamp only knows about integers, and only about positive numbers, for that matter. You can't declare anything to be -0.0341 - that's completely Greek, as it were, to the Stamp. Notice that the sample program uses $0139 to represent +1.22. Tracy will explain how you find the number you're going to use (<--- this is known as "passing the buck"), but it's going to look something like this.
As far as dealing with a curve instead of a straight line, curves have simple equations as well. They're not linear, of course, so it's not just y = mx + b: there IS no "slope-intercept" form. There'll be another term, with x raised to some power (2, in your case, probably). Now you might have a good enough fit to a line that you don't need to bother with that. Or you might discover that it's not simply y = ax2 + bx + c, but rather is better fit by some other kind of function. Whichever it turns out to be, you just have to find the equation, and then the way of getting the Stamp to do the integer math equivalent of that equation. But of course that's all Tracy's department. <grin>
===================
I might wind up having to shield something on the GPS gizmo, but I don't think that's the problem, as it works (unshielded) on a protoboard. I think the problem has to do with how signals and power are carried on the pc board's traces, but again, this is all beyond me as well. I'll be out hat in hand looking for advice when I get a chance.
The GPS takes forever (20 minutes?) to get a valid signal, and loses that signal frequently, without ever locking again. That's unacceptable in a rocket tracker, of course. But again, on the protoboard it's up to a valid signal and 10 satellites inside of a minute or two after power up, and regains signal readily.
I only had the pc board manufactured, and there's no device for sale. If I get it working, I'll distribute a few to fellow rocketeers for more varied testing, and eventually consider selling the boards at a little over cost. I have no intention of going commercial - I don't have time or interest in supporting a product.
==============
The U.S. is down 0-1 to Ghana at the half. If we don't come back, we're out. The rest is single elimination.
1)·Why, or how·does the·constant·"Cnts2Mv"·equal the number·1.22 ?
Cnts2Mv CON···· $0139···· ' x 1.22 (To Millivolts)
How would you make a hypothetical·CONstant "Cnts2ppm" (converts to ppm) equal 0.0341?
Cnts2ppm CON···· $ ????·····' x·-0.0341 (To parts per million)
What about negative -0.0341?
DONOVAN SCORES............! Ghana with the corner kick. Looks like·the game might·go into a shoot-out.
UGH. Ghana just scored... at 92:55 in extra time. Game over. Very much over.·
·
I was very busy last week and had to tune out here, sorry. Actually, yes, it is good for you to figure things out by trial and error! Today I'm at the Propeller expo (UPEW) at Parallax headquarters. There is lots of energy here, and projects on display, and a couple of teachers are interested in doing rocketry projects with their students. Maybe they will chime in here.
One nice thing is that the kind folks at Parallax gave me a CO2 sensor and an MCP3202 so that I can try it out myself and follow along more closely with your progress and maybe give you better advice. I have some ideas about how to stretch out the resolution to give better resolution at the low end. I'll try it myself first though, before I really really suggest anything that voids your warranty!
Mark, the fact that data fields appear on a separate line is probably an artifact of your computer terminal (the debug screen). If the data line is too long, it wraps it down to the next line. Does that make sense in view of what you are seeing?
If you want the mV from the CO2 sensor to appear in the USB thumb drive file, you have to say,
That is because the program as written is logging the variable called CO2pp to the thumb drive, and right now that value is the 0 or 1 alarm status. Also, you have to comment out the line that reads the alarm status.
About */ Cnts2Mv, where Cnts2/Mv=$0139. I don't like to write it as a hex number. I just write it as decimal, $0139=313 in decimal. What do you get when you divide 313/256? 1.22265625. That is pretty close to the multiplier 1.2207 that we need to convert counts to millivolts. That is the way the BASIC stamp does fractions. Internally, when the Stamps comes across this expression,
it multiplies result0 times 313 and then divides that by 256.
The graph shows that the mV output of the sensor is inversely proportional NOT to CO2 ppm directly, but to the logarithm of CO2 concentration. Even with that in mind, it is not exactly a straight line and curves around at low levels. It is hard to tell from that graph what to expect at lower CO2 concentrations. That is part of why we were talking about interpolation vs extrapolation.
@ Paul, the problem with the GPS may be due to what is near it on the circuit board. If circuit board traces run under or even near the antenna, they can create interference patterns in the radio waves that it depends on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
It sounds to me·that you are saying that 1.22265625 goes to 1.2207. Is this correct? If so, how does the STAMP go from 1.22265625 to 1.2207? If you rounded it, wouldn't the outcome be 1.223?
Sean
· The Parallax/Propeller symposium sounds interesting. Was it a day-long event? What all did you do and see there? Did a lot of people attend? Did you present? I'd love the opportunity to come out and see the whole Parallax operation·some time. I'm glad you got a CO2 sensor and an ADC chip (if·I had known you didn't have them we would have sent you some.) How far is Parallax from where you are?
Thanks for posting the code to make the CO2 sensor's millivoltage show up on the flash drive.·The mV shows up on the flash drive now. Plus, adding this new·code confirmed·something that we thought was happening (or rather, wasn't happening): the mV·that indicates CO2·fluctuation does NOT change at all when pure CO2 is applied to the sensor.
Chris and I·back-tracked to page 8 of this forum and we re-built the CO2 sensor "test stand"·on·a separate·BOE protoboard. We wanted to·double-check that the sensor itself was working. However, when we wired the·third BOE and ran the page 8 code (below)·the same thing happens as above: there is no mV fluctuation when pure CO2 is applied to the sensor. Voltage drops and stays at '0' at TP1 - TP2.
From page 8:
1) Connect voltmeter between TP1 and TP2 - Check
2)·Connect Vin to Vin on BOE - Check
3) Connect 'Com' (GND)·to Vss on BOE - Check
4) Connect CNTL to p4 on·the Stamp·with a 1000 Ohm resistor between p4 and CNTL - Check
5) Connect the ALR· to pin p3,· also via a 1000 Ohm resistor - Check
6) Run program below. Now observe the voltmeter connected between TP1 and TP2·- NO VOLTAGE CHANGE when pure CO2 is applied. Voltage drops to '0'·at TP1 - TP2 and stays there.
After 3-1/2 hours of troubleshooting the problem from every angle we know (and after considering a walk to the garage to get a sledgehammer for 'the ultimate fix'), we made a discovery. When·you connect the wire from the CO2 sensor's 'Vin'·pin to·the proto-BOE's·'Vdd' pin (NOT Vin-to-Vin), mV does fluctuate at TP1 and TP2 when·pure CO2 is applied.
We·tried the same fix on the ASP-BOE-CO (switched the input wire to Vdd instead of Vin) without success. We tried (somewhat randomly, because we'd been at it for hours, and we were hungry) switching a few other Vss/Vdd/Vin wires to the ASP-BOE back and forth without success.
Conclusions:
1) The mV representing CO2 on the ASP-BOE does NOT represent CO2 fluctuation (it didn't change at all when pure CO2 was applied.) As it's wired now, millivoltage at TP1 - TP2 drops·to and then remains near '0'.
2) The same thing occured when the 'CO2 test stand" was wired Vin-to-Vin. Wiring it Vin-to-Vdd·seemed to fix the problem.
3) We suspect the breadboard is currently wired incorrectly. Attached is a wiring schematic for the stand-alone breadboard wiring. I will hide the sledgehammer for now.
Tracy and Sylvie, Andrew and Rocketeers, friends, Romans, and countrymen·- Would you mind looking at the attached wiring schematic and see if you can locate the wiring (?) gremlin that's causing the CO2 sensor not to show a millivoltage change? If that's not it, then what? The sledgehammer...?
Thanks! Now we will eat breakfast (2:55 PM).
Mark and Chris
I'm a bit surprised to see that you have TP1 from the sensor wired to channel 1 (rather than channel 0) on the 3202. It will work that way, but you need to be aware that the CO2 level will be coming through that channel. Make sure that's the one you're reading in your software. You have (according to the wiring diagram) the output of the CO2 sensor's potentiometer wired to channel 0, so if your software is reading only that channel, you will only see variations when you adjust that pot.
I'm not sure why you have 1K resistors going from the sensor's TP1 and TP3 to the 3202's input pins. Tracy may have suggested that and I just missed it: I wouldn't have used them, myself. In addition, if your diagram is meant to represent how things are placed on a protoboard, those resistors don't seem to be doing anything. Every pin in a row of a protoboard is connected to every other pin in that row, so if both ends of the resistors are in the same row, it's just spare parts, essentially (I guess it would amount to a resistor wired in parallel with a wire, but that's essentially a 0K resistor). Now, I'm not sure you mean the diagram to be read that literally - it has something similar for the resistor on the Din and Dout pins, but I don't think that's what you have there.
Do you know the difference between Vin and Vdd? On the BoE, Vdd will be 5V (or something very close to that). Vin will be whatever voltage you're feeding TO the BoE from your battery. The CO2 sensor's Vin pin is supposed to require 6.5V to 12V, so Vdd should _not_ work (which is, of course, the opposite of what you're reporting here). It needs more than 6V because it supplied 6V to the heater circuit to get that to work properly.
When you're making your measurements, is the heater circuit on? I suspect that's determined by your software - it depends on where the CNTL pin of the CO2 sensor is connected. If it's not connected, that's your problem. If it's connected to one of the BoE i/o pins, that pin needs to be programmed to turn on the circuit. Tracy will help you determine that part (as, again, I'm going to try to avoid messing with your code).
Because the Basic Stamp only does integer math, you have to use this kind of trick to represent fractions. 313/256 is as close as you're going to get to 1.2207, and it's close enough: your error is in thousandths of millivolts (that is, less than millionths of a volt), and the hardware itself introduces bigger errors than that. If you were to pick the next number down to try to get closer, you'd have 312/256 = 1.21875, which is just about exactly the same error, but on the other side. It won't help you any. And you can't use 312.5/256 (which would give you almost exactly 1.2207), because 312.5 is not an integer, and so the Stamp can't use it. You could do some tricks, but they'd come at a cost, and again, the error is so small that it wouldn't gain you anything.
Tracy -
I don't want to hijack things here with trouble-shooting about my GPS board, but I will·probably post a question about it to the Sandbox sometime in the next couple of days·if I don't find a wiring issue that fixes it. I did run wires·from the GPS module to the pc·board's GPS connections, separating the module from the traces,·without any improvement.
I think Tracy suggested resistors for CH0 and CH1 a few pages back-- which is why they're there-- but I'll go back and check again just to be sure.
The resistors·are "in-line"; that is, they're in the same "row" as the CH0 and CH1 ADC pins (between the ADC pin and the wire to the BOE.) The picture may be misleading (oops!)
I removed both resistors, ran the program again, and got the same results (oops!)
Yes, Vdd is regulated to 5 volts, right? And Vin is "full, direct voltage" (e.g. if the source is 9.2 v, you get 9.2 v if the wire is connected to Vin. Yes?
With that said, so why does the sample code run the CO2 test set-up OK with Vdd and not with Vin (which is how it's "supposed" to be wired. I'm getting up to my ears in alligators and my head is swirling around...!
The program code indicates that the·heater (CNTL/HSW) is turned on so I'm assuming it is.
Stumped,
Mark
I saw Argentina crushing Mexico 3-0 a little while ago. And the US sure lost a heartbreaker, didn't they? I couldn't believe·it when·Ghana scored so late in the game (and I can't believe I'm actually watching soccer!) Not long ago it was not on my 'top 10' list of fun things to do. My how things change!
·················
/\/\/\/
====
|
|
=====
3202 pin --- 1 resistor lead --- other resistor lead --- wire going to BS2 on BoE
If that's the case, then the resistor is doing nothing. If you want a resistor in series with the connection from a 3202 pin to a BS2 pin, you need to have one lead of the resistor in the protoboard row with the 3202 pin, and the other lead in a completely separate row, with the wire going out to the BS2 in that second row as well.
Sorry if I'm misunderstanding things and you already knew this.
In general in electronics, it is wise to include some sort of protection in wires that go "off-board". A resistor is the first line of defense as it limits current to a safe level.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Still, if the resistor is connected the way it sounds like it's connected, it's not meeting that purpose - the excessive current would simply bypass the resistor and run right in through the protoboard's connection. Right?
··We connected the resistors and wires the way Sylvie suggested. We also ran the program without and resistors. Finally, we put the resistors back·like I had them originally (see diagram·above.) The results were the same in all three configurations: voltage could be·adjusted·with the potientiometer but the CO2 sensor/voltage was unresponsive·(showed no fluctuation at all when pure CO2 was applied.)
Tracy, we'll install a new ADC chip "just in case" we cooked the one currently·on the board when we were fiddling with the wires (or as you said, "...in the unlikely event that someone connect(ed) that pin to Vin by mistake." By mistake? Who...US?! The likelihood of that happening is about as likely as Ghana·beating the US soccer team in the World Cup.)
Mark
Mark
·
Your wiring photo looks good. Checking here. You do have Vss connected to Vss on the module, right?
Do you have a multimeter that lets you measure what is coming out on TP1 and to compare that with what is going in to ch0 on the ADC?
Please post the code you are using for this test, and a photo that shows how you have it hooked up to the CO2 sensor. I have the ADC hooked up here, but not yet the CO2. The ADC seems to be working fine.
Here is my diagram taken from an earlier one you posted:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com