I think that where we are in the project it is looking grim for going to Nevada, for my sub system team especially. We need to get a move on. I am available this weekend Justin but like Mr. K said will we get a good amount done?
Emily
Just as a reminder, we really d I o appreciate the help that you are giving us. Andrew andhave been stuck on this problem for quite a while now. And now it seems that we are close to finally addressing how to fix the problem.
So, what's the scoop on the MAWD's data?
It's a binary number, it sends ASCII code?
Andrew and I do not know much at all about the MAWD, and how it's inner-workings really function.
in re. my e.g. %00000001 11110100 is 500 (decimal) expressed as a binary number (a Word = two bytes = 16 bits.)
OK, got it I think. 11110100 is the DEC version of the number 500, written in binary. Yes? What does the modifier "%" do?
MAWDin is the name of the Stamp input pin where the data output from the MAWD (what I'm calling the "MAWD data") goes.
OK, I understand that, too.
So there's an ADC between the MAWD and the Stamp?
Yes. How does that affect things from your perspective?
The DEC modifier means that a character, a code, representing a decimal number is expected, as opposed to the number itself. For "0"-"9" then the SERIN is waiting for a code/byte in the range of $30-39 ($30 = "0", $31 = "1", and so on.) As described in PBASIC Help, The DEC formatter "tells SERIN to convert incoming text representing decimal numbers into true-decimal form and store the result in sData." That'd be some kind of ADC. Ordinarily, an ADC would output a binary number unless there was other circuitry which configured that as ASCII/text characters.
I understand the theory here but I'll have to re-read your information, read the book a bit futher, then mull it over... and over, and over until I can get my head wrapped aroound it in the context of the overall program.
Intriguing.
No doubt about it!
Here's what we're trying to do and here's where we're stuck:
We're trying to make the MAWD turn on a "movement" subroutine after the rover lands and the MAWD reads/writes a series of (twenty or so) consecutive 0's. The zeroes confirm that the rover has, in fact, landed before it starts the servos/wheels moving.
Andrew and Dylan wrote a subroutine to make the MAWD read a series of zeroes after the rover lands. However, when we add their subroutine to the original "main" program I posted above, then run the BOE rover in a vacuum chamber (to simulate altitude and activate the MAWD), the servos don't run at all although the MAWD does record "altitude."
Andrew and Dylan, please post your current version of the program.
The theory of writing the program code to activate the servos seems straightforward:
IF altitude = 000000000000000 feet, the GOSUB "movement"
We're stuck because we're not sure of the correct PBASIC syntax and the correct order of the program code. That's the long and the short of it.
The program I attached above DOES NOT have the "movement" subroutine. I've attached an older version of the program called "JUNK-MAWD..." which has the movement subroutine at the bottom of the program. It's commented out.
What information do you need from us to help move us along?
Also to add to Mr. Kibler's post.
That program does not have the sections that Andrew and I added that activate the movement once it has landed. It only has our program from last year with an attached movement subroutine.
The 9600bps 8N1, I gather.
Can you run that MAWD on the bench?
So, if the DEC5 is valid (??) then it's dumping ASCII; it's possible, but I remain a skeptic.
If you had a serial LCD that did 9600bps then you'd see numbers, if it was ASCII; otherwise it'd be gibberish.
Can you contact/email PerfectFlite and make inquiries?
PE -- % denotes a binary number / expression (follows)
Also to add to Mr. Kibler's post.
That program does not have the sections that Andrew and I added that activate the movement once it has landed. It only has our program from last year with an attached movement subroutine.
Yes, that's also correct Dylan. Can you please post the program that you and Andrew wrote-- the one with the "movement" subroutine activated by the MAWD-- so we're all working with the same version of the program? Otherwise things will get confusing.
The 9600bps 8N1, I gather.
Can you run that MAWD on the bench?
I'm not sure what you mean by this. We can put the entire MAWD + BOE + CO2 sensor + ADC apparatus in a bell jar and draw a vacuum to activate the MAWD (altimeter.)
So, if the DEC5 is valid (??) then it's dumping ASCII; it's possible, but I remain a skeptic.
If you had a serial LCD that did 9600bps then you'd see numbers, if it was ASCII; otherwise it'd be gibberish.
The program runs perferctly using DEC5 (there is a comment, a short discussion, in the program about using DEC5 instead of the alternative STR.) Can we assume then, that the BOE 'is reading and interpreting ASCII from the MAWD? We've never seen gibberish appear on the GUI.
Can you contact/email PerfectFlite and make inquiries?
Yes, but sometimes they're s l o w and sometimes cranky. What would I "ASCI" them if I were to e-mail?
I think that where we are in the project it is looking grim for going to Nevada, for my sub system team especially. We need to get a move on. I am available this weekend Justin but like Mr. K said will we get a good amount done?
Emily
Well, I guess we won't get much done if we don't talk on the forum first. I think it would be good to have a few basic ideas that we could try when we get together. Did you look at my other post? Do you think that has any potential? Can you think of another mechanical way to release it, since that seems to be where we need to take it if at all possible? I'm still hoping Obie can reply to give us an idea of what he and his Dad were talking about. I hope to see him on Thursday, so I might be able to talk to him more then, too. The best day for me to meet would be Sunday afternoon. We could meet here, if you would like. I will be on a camping trip with Boy Scouts on Saturday, but I could have my Mom pick me up and bring me to a meeting, or have one at my house, if needed, and then she would just bring me back. Anyway, since you and Jake are the veterans, and I'm still just a candidate, I'll let you guys tell me how you want to go forward. I'm just trying to put out ideas to at least get people thinking.
Could you ask them if it sends ASCII?
I guess it does, but, but...
Have you ever DEBUGed the MAWDin feet in the chamber/bell jar?
Yes, we have put the MAWB-BOE in the bell jar with a serial cable attached (*I had to smash the cable flat with a hammer so it would fit under the bell jar. Then I sealed it with LOTS of Vaseline!) When we run the program with the MAWD-BOE in the vacuum chamber we get good data stream on the GUI... "live time" altitude, CO2 (mV), etc.
Anyway, since you and Jake are the veterans, and I'm still just a candidate, I'll let you guys tell me how you want to go forward.
Well I wouldn't call them "veterans" since this is their first year on the team, too. Jake and Emily are only about 4 practices ahead of you Justin. You're doing fine.
Now if you want to talk about veterans, talk to Andrew. HE'S been doing these projects since he was in 4th grade! In fact, he knew Abraham Lincoln. They did a robotics project together.
It might be valuable to do nothing but a stripped MAWD data, zerocounter status, thousand counter status program test, wring it out.
To what end? To test functionality? We could just put the MAWD in the bell jar and activate it, then listen for the number of "beeps" (e.g, for 925 feet, 9 beeps = 900 feet (or 90 feet), then 2 beeps (20 feet), then 5 beeps (5 feet) to verify that the MAWD works. We know that it does and we have proof of concept that it reads and writes data to the Data Logger.
PE -- the bicycle pump thing, you don't need 3050m, just some change, make some numbers (danged numbers, sorry)
Yeah, we could just attach a large plastic syringe (or a turkey baster?) and draw a vaccum. No need to run the vacuum up to 3,000 m when we just want (danged) numbers.
Has any of your testing included DEBUGing the "zerocounter" and "thousand counter" results?
(Mr. Kibler,
Zerocounter and Thousandcounter are the variables that Andrew and I used in our program to store the values of how many 1000's are recorded after take off, and how many 0's are recorded when it touches down.)
I understand what you mean by that. As in making sure that the values are increasing by debugging the value somewhere in the subroutines.
No we have not tried that, but it certainly seems like the next logical step. And I have a question about that...
Who agrees, (Mr. Kibler, Andrew), with inserting such DEBUG commands into our code to to check if the values are increasing? It shouldn't be complicated unless there are already existing problems... But it seems well worth our time, as it shouldn't take more then an hour to modify the program. Andrew and I could do this quickly.
***Although, I just remembered that these tests would require us to attach the 9-pin cable through the bell jar, to the computer, involving the hammer and such. Mr. Kibler, would it be possible that you could conduct such tests again? You could send us the flash drive results, as well as a copy'n'pasted log of what was displayed on the GUI. This is my last post of the night and I will check again tomorrow after school for your replies..
Mr. Kibler, would it be possible that you could conduct such tests again? You could send us the flash drive results, as well as a copy'n'pasted log of what was displayed on the GUI. This is my last post of the night and I will check again tomorrow after school for your replies..
Yes, was the plan and that's the deal. You and Andrew and PJ (and everyone else) write the program and I'll run it in the bell jar between practices. Then I'll report back to everyone on the forum so you can modify the program.
We can't afford to wait two more weeks just to run one experimental trial. We need to be doing exactly what we started tonight, with lots of trials, until we get it figured out. Otherwise we won't get it done in time for the lanuch in Nevada. We have a month to get it fully operational. That's it.
I'm off to bed too. Thanks PJ ~ !! You're our hero. :cool:
Good "practice" tonight everyone. Don't stay up too late staring at cathode ray tubes.
I'm baffled that the manufacturer cannot just lay it out there for the great unwashed - "Altimeter data, in feet, is output as 5 ASCII characters."
Dispel all doubt or leave 'em guess.
They're very explicit, proud (smug), in regard to the stellar achievement that is the beeping, though.
Wow.
Comments
Emily
There is no ADC chip connecting to the MAWD. We used the ADC chip for a CO2 sensor that we added to the ASP last year.
Dylan Landry
It's a binary number, it sends ASCII code?
If any of you are "handy" you could make your own vacuum chamber to wring that device out with this
http://www.instructables.com/id/make-a-manual-vacuum-pump-for-under-$20-by-convert/
PE -- with that, you could "get some numbers", as we say
PPE -- Sorry, that's "get some danged numbers"
Just as a reminder, we really d I o appreciate the help that you are giving us. Andrew andhave been stuck on this problem for quite a while now. And now it seems that we are close to finally addressing how to fix the problem.
Andrew and I do not know much at all about the MAWD, and how it's inner-workings really function.
This is the information that we can accumulate from the manufacturer of the MAWD. This maybe can answer your question.
OK, got it I think. 11110100 is the DEC version of the number 500, written in binary. Yes? What does the modifier "%" do?
OK, I understand that, too.
Yes. How does that affect things from your perspective?
I understand the theory here but I'll have to re-read your information, read the book a bit futher, then mull it over... and over, and over until I can get my head wrapped aroound it in the context of the overall program.
No doubt about it!
Here's what we're trying to do and here's where we're stuck:
We're trying to make the MAWD turn on a "movement" subroutine after the rover lands and the MAWD reads/writes a series of (twenty or so) consecutive 0's. The zeroes confirm that the rover has, in fact, landed before it starts the servos/wheels moving.
Andrew and Dylan wrote a subroutine to make the MAWD read a series of zeroes after the rover lands. However, when we add their subroutine to the original "main" program I posted above, then run the BOE rover in a vacuum chamber (to simulate altitude and activate the MAWD), the servos don't run at all although the MAWD does record "altitude."
Andrew and Dylan, please post your current version of the program.
The theory of writing the program code to activate the servos seems straightforward:
IF altitude = 000000000000000 feet, the GOSUB "movement"
We're stuck because we're not sure of the correct PBASIC syntax and the correct order of the program code. That's the long and the short of it.
The program I attached above DOES NOT have the "movement" subroutine. I've attached an older version of the program called "JUNK-MAWD..." which has the movement subroutine at the bottom of the program. It's commented out.
What information do you need from us to help move us along?
Mark
:cool:
That program does not have the sections that Andrew and I added that activate the movement once it has landed. It only has our program from last year with an attached movement subroutine.
Dylan is correct on this. The ADC is for the CO2 sensor, not specifically for the BOE. But some (4 or 5?) of the wires from the ADC do go to the BOE.
Can you run that MAWD on the bench?
So, if the DEC5 is valid (??) then it's dumping ASCII; it's possible, but I remain a skeptic.
If you had a serial LCD that did 9600bps then you'd see numbers, if it was ASCII; otherwise it'd be gibberish.
Can you contact/email PerfectFlite and make inquiries?
PE -- % denotes a binary number / expression (follows)
Yes, that's also correct Dylan. Can you please post the program that you and Andrew wrote-- the one with the "movement" subroutine activated by the MAWD-- so we're all working with the same version of the program? Otherwise things will get confusing.
Thanks,
Mr. Kibler
I'm not sure what you mean by this. We can put the entire MAWD + BOE + CO2 sensor + ADC apparatus in a bell jar and draw a vacuum to activate the MAWD (altimeter.)
The program runs perferctly using DEC5 (there is a comment, a short discussion, in the program about using DEC5 instead of the alternative STR.) Can we assume then, that the BOE 'is reading and interpreting ASCII from the MAWD? We've never seen gibberish appear on the GUI.
Yes, but sometimes they're s l o w and sometimes cranky. What would I "ASCI" them if I were to e-mail?
Mark
:nerd:
I guess it does, but, but...
Have you ever DEBUGed the MAWDin feet in the chamber/bell jar?
Thanks Dylan. That was fast. Let's all use this version of the program for now. OK? That way we're comparing apples to apples.
Mr. Kibler
Well, I guess we won't get much done if we don't talk on the forum first. I think it would be good to have a few basic ideas that we could try when we get together. Did you look at my other post? Do you think that has any potential? Can you think of another mechanical way to release it, since that seems to be where we need to take it if at all possible? I'm still hoping Obie can reply to give us an idea of what he and his Dad were talking about. I hope to see him on Thursday, so I might be able to talk to him more then, too. The best day for me to meet would be Sunday afternoon. We could meet here, if you would like. I will be on a camping trip with Boy Scouts on Saturday, but I could have my Mom pick me up and bring me to a meeting, or have one at my house, if needed, and then she would just bring me back. Anyway, since you and Jake are the veterans, and I'm still just a candidate, I'll let you guys tell me how you want to go forward. I'm just trying to put out ideas to at least get people thinking.
Yes, we have put the MAWB-BOE in the bell jar with a serial cable attached (*I had to smash the cable flat with a hammer so it would fit under the bell jar. Then I sealed it with LOTS of Vaseline!) When we run the program with the MAWD-BOE in the vacuum chamber we get good data stream on the GUI... "live time" altitude, CO2 (mV), etc.
Why?
DEBUG DEC5 feet, CR
Well I wouldn't call them "veterans" since this is their first year on the team, too. Jake and Emily are only about 4 practices ahead of you Justin. You're doing fine.
Now if you want to talk about veterans, talk to Andrew. HE'S been doing these projects since he was in 4th grade! In fact, he knew Abraham Lincoln. They did a robotics project together.
Mr. Kibler
Very solid number all the way around using DEC5 (see attached.) DEC5 seems to work fine.
The August 7, 2010 file (below) has all the sensors up and running.
No, we ran the BOE inside the bell jar with all the sensors, including the MAWD, activated (see the August 7 data file I just posted.)
I was looking over the program this morning and the DEC5 struck me as odd.
I guess it's so.
And I was sketching out the GOSUBs and RETURNs. Let me review that.
PE -- the bicycle pump thing, you don't need 3050m, just some change, make some numbers (danged numbers, sorry)
PJ,
An e-mail has been sent to Peter at PerfectFlite asking him if the MAWD outputs ASCII.
Mark
To what end? To test functionality? We could just put the MAWD in the bell jar and activate it, then listen for the number of "beeps" (e.g, for 925 feet, 9 beeps = 900 feet (or 90 feet), then 2 beeps (20 feet), then 5 beeps (5 feet) to verify that the MAWD works. We know that it does and we have proof of concept that it reads and writes data to the Data Logger.
Yeah, we could just attach a large plastic syringe (or a turkey baster?) and draw a vaccum. No need to run the vacuum up to 3,000 m when we just want (danged) numbers.
But why?
I'm not sure what that means. The MAWD altitude always starts and "0" and runs up through 10,000 feet, then decreases to "0" again:
From Excel:
0:00:00 0
0:00:00 0
0:00:00 0
0:00:04 6
0:00:10 16
0:00:12 77
0:00:13 495
0:00:15 855
0:00:16 1119
etc ---> to 10,000+ feet and then back to "0"
(Mr. Kibler,
Zerocounter and Thousandcounter are the variables that Andrew and I used in our program to store the values of how many 1000's are recorded after take off, and how many 0's are recorded when it touches down.)
I understand what you mean by that. As in making sure that the values are increasing by debugging the value somewhere in the subroutines.
No we have not tried that, but it certainly seems like the next logical step. And I have a question about that...
Who agrees, (Mr. Kibler, Andrew), with inserting such DEBUG commands into our code to to check if the values are increasing? It shouldn't be complicated unless there are already existing problems... But it seems well worth our time, as it shouldn't take more then an hour to modify the program. Andrew and I could do this quickly.
***Although, I just remembered that these tests would require us to attach the 9-pin cable through the bell jar, to the computer, involving the hammer and such. Mr. Kibler, would it be possible that you could conduct such tests again? You could send us the flash drive results, as well as a copy'n'pasted log of what was displayed on the GUI. This is my last post of the night and I will check again tomorrow after school for your replies..
Why? Help us understand why DEC5 stood out as different from STR. What were you looking for that made you notice it?
Yes, was the plan and that's the deal. You and Andrew and PJ (and everyone else) write the program and I'll run it in the bell jar between practices. Then I'll report back to everyone on the forum so you can modify the program.
We can't afford to wait two more weeks just to run one experimental trial. We need to be doing exactly what we started tonight, with lots of trials, until we get it figured out. Otherwise we won't get it done in time for the lanuch in Nevada. We have a month to get it fully operational. That's it.
I'm off to bed too. Thanks PJ ~ !! You're our hero. :cool:
Good "practice" tonight everyone. Don't stay up too late staring at cathode ray tubes.
Mr. Kibler
:nerd:
Dispel all doubt or leave 'em guess.
They're very explicit, proud (smug), in regard to the stellar achievement that is the beeping, though.
Wow.