Here are the pictures of our 'pod' with the BOE on it and our GPS transmiter. Hope this helps. What does everyone think? What are your thoughts, observations and ideas?·Thanks again for all of your replies and help.
I'm not quite sure why you're using a mosFET to turn the datalogger on and off. It's standby current is only 2ma, plenty low enough for waiting around for a couple of hours.
Sean, Is there clearance for the USB flash drive? It it is a GPS to ground transmitter, is the RF from the rubber ducky antenna going to affect the BASIC Stamp, so close? How is the GPS powered?
Sylvie, what does the telemetry look like on the capture screen? I read your interesting article. If there are say 7 bytes per altitude message, and they are emitted 20 per second at 9600 baud, that would leave about 43 milliseconds of silent time between messages, which would help the Stamp to synchronize. At 9600 baud the Stamp works most effectively with the STR modifier, and unfortunately, the WAIT or DEC modifiers are too slow. I think I picked up the 20 per second figure from SRLM's post a few back.
·· We'll be using a shorter flash drive with lots of memory, so (physical and memory) space isn't a real concern. We also have the opposite side of the wooden board available to mount on (perhaps two BOE's...?)
The orange transmitter with the black rubber antenna is a Garmin DC 20 (DC = dog collar) transmitter. It claims a 5-mile range which we hope is ample in the Black Rock desert. They also make a DC 30 which claims 7 miles transmit distance. Our budget didn't allow for the recommended 'BigRedBee' Beeline shortwave transmittter, which claims a 35-50 mile line-of-sight range. The receiver is a Garmin Astro 220 GPS, programmed to receive a signal from the orange DC 20. Bulky, yes; affordable: barely. But it's what have to work with (and it's all my wife would allow me to spend. She said: "Be sure to keep the receipt!) Question: what should I do with the receipt if the whole apparatus drifts off into the desert, never to be seen...? I won't ask her!)
I'm intrigued by the possibility of streaming altitude data directly to the BOE/Datalogger from the MAWD like Sylvie proposed. I think it's an elegant·idea and it 'seems' within our technical grasp, with everyone else guiding us along. The students are really excited-- and a bit surprised-- by the excellent suggestions and information we've received so quickly.·Thanks! You're inaugurating some newbies into programming and electrical engineering in fine fashion!
Sylvie, please keep us up-to-the-minute, especially when you receive data on the BOE from the MAWD!
There is also the current requirement of the disk itself, which in ones I have tested will be around 40 mA addition to the current drawn by the datalogger interface. The highest USB supply current (90 mA) I have seen was from a Sandisk drive that also folded up to become an SD card.
You are quite right, though. By using the SUD command, the disk itself can be turned off, down to 20 mA for the interface alone, and then WKD wakes it up. Furthermore, the SUM command turns off both the disk and the monitor interface, down to less than 2 mA. Then it takes a ping on the hardware RI line to wake it up. I don't think those capabilities are implemented in the Rocketeers' firmware and hardware, and it would certainly be worthwhile to do so if they go that route.
Personally, I favor the zero-power external switch, for a couple of reasons. For my own purposes I am usually thinking that even 2 mA is way too much. But as you point out it would not be too much for a couple of hours sitting around on a launch pad. Even if the power were less though, I like the fact that the external control avoids all problem with initialization. The drive always comes up in a known state at power up. Without that, I have found that it occasionally (and especially during development) will glitch off into la-la land, without resolution.
Sylvie, what does the telemetry look like on the capture screen? I read your interesting article. If there are say 7 bytes per altitude message, and they are emitted 20 per second at 9600 baud, that would leave about 43 milliseconds of silent time between messages, which would help the Stamp to synchronize. At 9600 baud the Stamp works most effectively with the STR modifier, and unfortunately, the WAIT or DEC modifiers are too slow. I think I picked up the 20 per second figure from SRLM's post a few back.
The data look like this:
00040crlf
00042crlf
00046crlf
00051crlf
00055crlf
and so on. It sure looks like 7 bytes per altitude message, and yes, 20x/second with the MAWD (and that's not adjustable either). I'll play with this as soon as I have some time - maybe post a screen capture from the terminal program, and try it with a Stamp.
Sylvie, the fixed-length field helps. As a quick test, I emulated the telemetry on a BS2px (for intercharacter speed), and received it on a BS2:
[color=#FFA500]' {$BS2PX} emulate transmitter
' {$PBASIC 2.5}
idx VAR Word
DO
idx=idx+1
PAUSE 42 ' this gives about 20 per second
SEROUT 5,396,[noparse][[/noparse]DEC5 idx, CR, LF] ' 7 character message at 9600 baud true
LOOP[/color]
' {$BS2}
' {$PBASIC 2.5}
array VAR Byte(7)
DO
SERIN 5,84,40,escape,[noparse][[/noparse]STR array/7]
IF array(6)=LF THEN DEBUG STR array\7 ' LF in array(6) means good data.
escape:
LOOP
The BS2 was able to keep up, although it would often take one iteration to get resynced after a reset.
Tracy Allen said...
Sylvie, the fixed-length field helps. As a quick test, I emulated the telemetry on a BS2px (for intercharacter speed), and received it on a BS2:
Okay, I just hooked it back up through the serial cable and ran the terminal program stuff, and captured the data coming out from a simulated flight. Here (attached) are those data (this is just me sucking on the rubber tube to change the pressure). It does come as a long series of 5-digit numbers with leading zeroes, separated by cr/lf, as I thought I'd remembered.
I sure wish I had time this morning to do more - this is far more interesting than the meeting I'm going to.
More when I have the chance.
Edit: Woo-hoo! It seems to work with the XBee. I attached the cable to the XBee RX/TX pins (and a common ground), simulated a flight, and I see the TX light on the XBee board lighting up rapidly as the data should be transmitted. I don't have time right now to set up a receiver, but it sure as heck is transmitting something, and exactly when I'd expect it to (it sits idle until I bring down the pressure in the test bottle, so the altimeter thinks it's flying and starts sending altitude data, and then it transmits until the pressure is back to normal, then stops).
Post Edited (sylvie369) : 6/12/2009 11:10:46 AM GMT
·· This seems like a 'eureka' moment!·The output from the MAWD to the Xbee sure looks like an altitude graph when the data is graphed on Excel. But·how does the·Xbee interface with the BOE? Or would·the·MAWD-XBee set-up·be separate from the BOE? What we'd like to do is stream data from the MAWD, through the BOE, and onto the Datalogger where it will be correlated with temperature, humidity, and time·(all on one data dump from the Datalogger/flash drive to an Excel spreadsheet.)
Excellent progress; we're eager to hear even more! *And yes, I·agree with you about·about going to meetings, etc. Working on the hardware/software challenge is preferable to coming in to school (though Jess and Thomas and Sean are in my last period STEM class. Can't wait to get there!
Mark
·· This seems like a 'eureka' moment!·The output from the MAWD to the Xbee sure looks like an altitude graph when the data is graphed on Excel. But·how does the·Xbee interface with the BOE? Or would·the·MAWD-XBee set-up·be separate from the BOE? What we'd like to do is stream data from the MAWD, through the BOE, and onto the Datalogger where it will be correlated with temperature, humidity, and time·(all on one data dump from the Datalogger/flash drive to an Excel spreadsheet.)
Excellent progress; we're eager to hear even more! *And yes, I·agree with you about·about going to meetings, etc. Working on the hardware/software challenge is preferable to coming in to school (though Jess and Thomas and Sean are in my last period STEM class. Can't wait to get there!
Mark
Mark -
Here's how (attached). It works. Oh baby. I removed the cable from the Data Transfer dongle, plugged it into·a MAWD whose telemetry I had already turned on. Then I connected the ground wire (the brown one) from the cable to a VSS connector on the Stamp board (I'm using a Supercarrier board instead of a BOE, but it'll work the same), and the cable's RX to one pin and TX to another on the Stamp. Then I ran Tracy's code (modified for the pins I was using and the fact that I'm using a BS2px instead of a BS2). Turn on the MAWD, let it go through the startup beeping, then suck on the tube to simulate flight, and watch the altitude numbers appear in the DEBUG terminal window. Worked perfectly. Attached is also a screenshot of the output.
Okay, it seems to work fine on the BS2 as well. Of course I can't be certain that I'm not missing some of the values - you're going to have to find that out for your own setup, I'm afraid. But it looks like it works, and it's pretty straightforward. The Data Capture cable has five pins: the middle one is the one that you connect to a Stamp I/O pin through a 10K resistor (and connect the brown ground pin on the cable to your BOE VSS), and then once the MAWD is set to do telemetry (which, again, you set through the Data Capture software, though you can do it through a terminal program instead if you prefer), you run some version of Tracy's little receiver program (the bottom piece of code in his post), and you'll get the altitude data in your BS2. From there, you can play with it to your heart's content.
Edit: Oh, it just occurred to me how to test to see if I'm missing values. Just download the data using the regular data capture software, after testing it with the BS2 and letting it record an entire "flight". That software gives all of the values, plus a convenient count of how many values were measured. I'll give that a shot too when I get a chance.
Post Edited (sylvie369) : 6/12/2009 7:10:22 PM GMT
·· This seems like a fairly simple, and elegant, solution. I just downloaded flight data from the MAWD to get a data count (1428 bits) to compare against the data/count we'll be getting from the BOE, to see if there are any missing values.
1) Now we're ready to begin surgery. There are FOUR wires on my Data Capture cable, not five: red, yellow, blue and brown. Our next step, it seems,·is·to "connect 'the middle wire' (the blue one?) to a Stamp I/O pin through a 10K resistor, then connect the brown ground pin on the cable to the BOE VSS." Is that correct?
3) After that we'll set the MAWD to do telemetry (through the Data Capture software like·you suggested.)
·· This seems like a fairly simple, and elegant, solution. I just downloaded flight data from the MAWD to get a data count (1428 bits) to compare against the data/count we'll be getting from the BOE, to see if there are any missing values.
1) Now we're ready to begin surgery. There are FOUR wires on my Data Capture cable, not five: red, yellow, blue and brown. Our next step, it seems,·is·to "connect 'the middle wire' (the blue one?) to a Stamp I/O pin through a 10K resistor, then connect the brown ground pin on the cable to the BOE VSS." Is that correct?
3) After that we'll set the MAWD to do telemetry (through the Data Capture software like·you suggested.)
4) Then run Tracy's receiver program.
What do you think? Should we proceed?
Yes, there are just four wires on mine as well (five locations on the connector, but one is empty). I'm not near mine right now, so I can't verify that it's the blue wire, but it is the middle one that sends the serial data from the MAWD, so yes, connect that one through a 10K resistor to an I/O pin, hook up·the brown wire to Vss on the BOE, and you're set, hardware-wise. Do not connect the other wires.
You'll need to make sure that Tracy's program refers to the I/O pin that you're using. He's set up for pin 5, and for a BS2 (so if you're using a different Stamp chip you'll need to adjust that 84 to some other value, maybe). But if you use pin 5 and a BS2, you should be able to run his program "as is".
·· Yes, I'm eager to see how it goes, too! We have a full team practice tomorrow afternoon and these young rocketeers are·eager to dive in and make it work. I suspect we'll have to tinker and 'tweak' it a bit (adjust the 84 to another value, for example, test the wires, and teach them how to set the MAWD for telemetry.) But ultimately I see this working... maybe not tomorrow, but soon. The kids are also excited that a local newspaper is coming out tomorrow (with a photgrapher!) to chronicle their adventures. We'll be sure to give you and Tracy and our Parallax friends due credit (maybe we should send CNN your way...!)
Our next challenge after we start to receive data will be to re-write the exisiting program so the altitude data is displayed and recorded on the Datalogger with time, humidity, and temperature. This was a fun and excellent challenge last year, especially since it was all new to me and the team. Some of the rockteers are returning team members and some are newbies, a 50-50 mix of each. So the learning curve is, well, interesting!
Tracy and Sylvie, I want you to know that your mentoring has paid these kids big dividends, the first of which is the ARLISS grant we received as a direct result of last year's project. One of last year's team members, Andrew, received a $7,5OO full scholarship to Phillip-Exeter's six-week summer STEM program. Exeter is a premier New England prep·school. Also, when they returned from college visits this spring, both Mollie and Tyler (and their parents) excitedly commented that virtually every college they interviewed at wanted to hear all about their involvement in rocketry, TARC, and NASA-SLI. Together Tyler and Mollie received 8 of the 12 awards at the spring academic awards banquet. Andrew also received a full scholarship to Sant Bani school next fall, a direct result of his involvement with FIRST/Lego robotics, TARC, NASA-SLI, and now, ARLISS.
I believe in paying forward,and it seems that you and Sylvie and our Parallax friends do, too. The paragraph above describes exactly what you've helped these kids achieve, in addition to excellent learning that's not quantifiable (the opportunity to rub shoulders with NASA engineers and astronauts, for example, and to crash rockets-- and learn something from it.) Thank you for helping them learn, succeed, and move on to the next level.·I appreciate all of your time, input, and efforts.
Thanks for the kind words. It's extremely rewarding to read this, especially as I believe that there is almost nothing more valuable right now than giving young students real hands-on experience with risky science and engineering projects (by "risky" I don't mean dangerous, but rather "not pre-packaged so that failure is impossible"). Tracy is the one who has donated real expertise here - I'm certain that if he had a MAWD sitting in front of him, he'd have had this all working a week ago (and I believe that you got considerable help from Mike Green and SLRM as well, right?). I have spare MAWDs to play around with like this because NASA/Wisconsin Space Grant Consortium funded two of my grant applications plus two student rocketry group entries in our state contests. If anyone wants a good example of your tax dollars going to good causes, there it is.
And of course you're the one doing the heavy lifting. As I said, I've worked with student groups. It's time-consuming and sometimes frustrating, even while being so rewarding.
With your permission, though, I'd like to quote your last post in my application for promotion this fall. Right now I'm listing my rocketry, ballooning, and electronics activities as "developing scholarship", but with this I could put it as "Serves the Wider Community" as well.
==========================
I'm home again, and can verify that it's the blue wire on the MAWD cable that carries the outgoing serial data. One challenge that's in front of you still is in programming: Tracy's code reads the digits and other characters into a 7-byte array. You need to turn the first 5 bytes of that array into a word-sized value in order to do things with it mathematically (notably figure out when the altitudes are starting to drop at apogee). It'll have to be a word rather than a byte because bytes only go from 0-255, while a word-sized variable can contain altitudes from 0 to 65535 feet (which is of course higher than you're ever going to need). If you know you're never going to exceed 10,000 feet you can throw out the first byte (or maybe first verify that it's a "0"), and just work with the next four, which are the 1000s, 100s, 10s and 1s of the feet of altitude. Tracy tells us
Tracy said...
If there are say 7 bytes per altitude message, and they are emitted 20 per second at 9600 baud, that would leave about 43 milliseconds of silent time between messages, which would help the Stamp to synchronize. At 9600 baud the Stamp works most effectively with the STR modifier, and unfortunately, the WAIT or DEC modifiers are too slow. I think I picked up the 20 per second figure from SRLM's post a few back.
The inability to use the DEC modifier at 9600 baud means that it may be necessary to keep using his method for reading the data. The mere "43 milliseconds of silent time" means, I think, that you'll have to do the conversion and the writing to the datalogger within 43 milliseconds. Tracy's website (see his .sig) includes this table of how long various commands take to execute:
Note that the times are in _micro_seconds, not milliseconds, so you get 43,000 of the table's units between inputs from the MAWD·to do all of your reading of data, conversion to word-sized variables, reading of other sensors, and writing to the datalogger. I think. Ask Tracy. Here is his page of valuable comments on reading serial data (including a section on reading high-speed data):
I'm very happy about good outcomes for these students, and for their mentors!
It looks from the first photo that you posted in this thread that you have available p3, p4, p6, p14 and p15, but not the p5 I used in my example program. Note in the photo that Sylvie posted, he used pin p15 instead of p5. Your choice. (Also observe that Sylvie posted one photo using the cool looking diagonally mounted BS2px and another using the BS2 OEM) 84 is the correct parameter for 9600 baud true on the BS2, and if that worked for Sylvie, it should work for you. The most likely alternative would be 16468, which is the parameter for 9600 baud inverted. Interested students should understand the difference between true and inverted. Let us know how it works!
There will be more learning maybe some transient frustration, and fun, to integrate this into your main program!
I used 84 on the BS2 (OEM) modules, and 396 on the BS2px module. Those were the values that worked.
I used those values simply because that's what you used (Tracy) in your sample code. I'm not exactly sure what the difference between TRUE and INVERTED is. I know that in one case (TRUE, I believe), 1s are represented by a positive voltage and 0s by no voltage (or a negative voltage, in some protocols). Is that correct? And then for INVERTED it's the other way around?
But what I really need to know, I think, is how to know whether a device wants a TRUE or an INVERTED serial connection. Someone once gave me a rule of thumb, but I don't remember it.
Yes, it is called TRUE because 1=HIGH and 0=LOW, whereas INVERTED has the logical meaning the opposite way from the voltage levels, 0=HIGH and 1=LOW.
Between transmissions, it rests at the level that represents a 1. For TRUE logic, that will be +5 Volts. Then to start a message it sends a start bit at 0 Volts, then the 8 bits of one byte, and then it goes back to the resting level +5 Volts for at least one bit period. That is called the stop bit, but it can stay at that resting level for any duration until the next byte is transmitted or received.
On old telegraph machines, the transmission was printed on a moving tape, and the pen was normally down on the paper, making a mark (drawing a line), so that was called "marking". Then when the start bit came over the wire, it would activate an electromagnet to lift the pen off of the tape, and that was called "spacing". The "marks" and "spaces" were translated into the 1s and zeros of the Baudot code or eventually to the ASCII code as we know it today. In literal sense you can look at the pen down as a physical low level that represents a logical 1. It was an INVERTED system. Most standard RS232 communication today is INVERTED, where a voltage like -10 Volts represents the mark, logical 1 and +10 Volts represents the space, the start bit, logical 0. But most microcontrollers internally use TRUE levels and send them through a hardware inverter to get to the outside world. The Stamp on its p16 DEBUG interface indeed has a hardware inverter, and the signals from p16 are always INVERTED. Is that confusing or clear?!
The bottom line is that the Stamp should be set to receive TRUE levels from the MAWK which is sending TRUE levels. Nothing bad will happen to the hardware if you mismatch the parameters. You'll just see garbage, or nothing.
You will find that the number of data points reported by the MAWD Data Capture program doesn't line up correctly with the number of data points captured to the Stamp. I think that once things get going, all of the data are captured, but the telemetry output doesn't start until the altitude is over 300 feet. I've run it a few times, and that's how it seems to go: you might be on the lookout for it as well. The Data Capture program might report several altitudes of a few feet up to a couple of hundred feet at the start of the flight, but the first data point reported by the Stamp (that is, the first one sent out through telemetry) is the first point over 300 feet. After that the two data sources seem to agree just fine.
I think that this is a matter of the MAWD's firmware. Every altimeter needs some set of parameters that tell it when the rocket has launched, so it can go from "ready" mode to "flight" mode. In ready mode the altimeter simply reads the altitude, waiting for a sign that the rocket has taken off. Once it believes that the rocket has taken off, it goes into flight mode, arming the apogee detect routine. That routine detects apogee by looking for an increase in atmospheric pressure. It cannot be armed on the pad because winds and simple changes in pressure might then cause your apogee charge to go off while you're still sitting on the pad: not pretty, especially if you're still setting up the igniter.
The MAWD detects flight by looking for a rapid increase in altitude. The documentation says "160 feet above the ground reading", but I believe that it's actually 300 feet (I have a·vague memory of someone saying that the documentation is wrong on that). I may be wrong, though: it might be 160 feet, and we're losing the first value, so that the first recorded value is actually the second value after launch. I'll run some more tests to look into that. It's not that big a deal.
The documentation says that "the previous 16 altitude samples are saved to logging memory", so the Data Capture software will report at least 16 pre-launch values that are not captured in the telemetry, so the number of data points reported by the two methods will be off by that much.
I'll look·into that 300 feet vs. 160 feet thing.
EDIT:
Okay, forget about the 300 feet stuff. It seems to be 160 feet, just as the documentation say. I also seem to be losing the first data point, at least with the BS2. For example, here are the first few data from my last run:
Reported by
telemetry:··· data capture:
················ (16 prelaunch data points ending with)
·················154
················ 154
················ 174
00183········ 183
00193········ 193
00212········ 212
00222········ 222
00212·········212
00212········ 212
00212·········212
00193········ 193
(etc.)
Post Edited (sylvie369) : 6/13/2009 6:25:49 PM GMT
I'm no rocketry expert by any stretch, but one thing that came to mind when I read the original post was something akin to a "dead man switch", but opposite in purpose. Here's a schematic:
When (and assuming) the payload detaches from the rocket, the phone plug attaced to the rocket pulls out of the socket in the payload, completing the power circuit to the data recorder.
If the Rocketeers have initial success with capturing the data, I'd like to ask them to do another experiment. That will be additional code to query the DS1302 real time clock they have in their system, and also to count out a number of receptions from the MAWD, and then the real time clock again. I want to verify the frequency that the MAWD sends out the data, how many free milliseconds between. Then I think it will be possible to fine tune the delays so that it will miss at most one reading. A reading will be missed if the program hits the SERIN command in the middle of a transmission, and the timeout in the SERIN should be adjusted so that it will miss at most one reading. A bad timeout value could make it miss several in a row.
Moving forward with the program, there are quite a few tasks that will have to be interleaved! There is the datalogger, the sensirion, the real time clock and decisions to be made in the program code.
You will find that the number of data points reported by the MAWD Data Capture program doesn't line up correctly with the number of data points captured to the Stamp. I think that once things get going, all of the data are captured, but the telemetry output doesn't start until the altitude is over 300 feet. I've run it a few times, and that's how it seems to go: you might be on the lookout for it as well. The Data Capture program might report several altitudes of a few feet up to a couple of hundred feet at the start of the flight, but the first data point reported by the Stamp (that is, the first one sent out through telemetry) is the first point over 300 feet. After that the two data sources seem to agree just fine.
I think that this is a matter of the MAWD's firmware. Every altimeter needs some set of parameters that tell it when the rocket has launched, so it can go from "ready" mode to "flight" mode. In ready mode the altimeter simply reads the altitude, waiting for a sign that the rocket has taken off. Once it believes that the rocket has taken off, it goes into flight mode, arming the apogee detect routine. That routine detects apogee by looking for an increase in atmospheric pressure. It cannot be armed on the pad because winds and simple changes in pressure might then cause your apogee charge to go off while you're still sitting on the pad: not pretty, especially if you're still setting up the igniter.
The MAWD detects flight by looking for a rapid increase in altitude. The documentation says "160 feet above the ground reading", but I believe that it's actually 300 feet (I have a vague memory of someone saying that the documentation is wrong on that). I may be wrong, though: it might be 160 feet, and we're losing the first value, so that the first recorded value is actually the second value after launch. I'll run some more tests to look into that. It's not that big a deal.
The documentation says that "the previous 16 altitude samples are saved to logging memory", so the Data Capture software will report at least 16 pre-launch values that are not captured in the telemetry, so the number of data points reported by the two methods will be off by that much.
I'll look into that 300 feet vs. 160 feet thing.
EDIT:
Okay, forget about the 300 feet stuff. It seems to be 160 feet, just as the documentation say. I also seem to be losing the first data point, at least with the BS2. For example, here are the first few data from my last run:
Reported by
telemetry: data capture:
(16 prelaunch data points ending with)
154
154
174
00183 183
00193 193
00212 212
00222 222
00212 212
00212 212
00212 212
00193 193
(etc.)
I actually don't think this will be a problem at all for us because our most important values will be on the way down after the rocket has already reached apogee. Will this completely solve the 160 feet problem?
By the way, this is Tyler from ARLISS NH. Thank you all for your continued support of our team.
Tyler from ARLISS NH said...
I actually don't think this will be a problem at all for us because our most important values will be on the way down after the rocket has already reached apogee. Will this completely solve the 160 feet problem?
By the way, this is Tyler from ARLISS NH. Thank you all for your continued support of our team.
Yes, I think that'd solve the 160 foot problem, if you don't care about values on the way up. It does continue to report·values below 160 feet on the way down.
I am not at all confident that it's reliably reporting all of the data values, though. Tracy's suggestions about adjusting the timeout values will be important.
I also just played around with using an XBee directly with the MAWD (for my own purposes: I know that won't work for you). It does work, and it's pretty slick to have nothing but the MAWD in a bottle with wires going to an XBee out in the kitchen, and to watch the reported altitudes appearing on my monitor on a computer connected to another XBee out in the living room. Unfortunately, it looks to me as though it's missing numerous values, which I find surprising. I might be wrong, though: the data captured on the receiver end always do include the value that the MAWD's memory reports as the peak altitude, and if I'm missing values, I'd have thought that one would have been among the missing from time to time.
I was hoping that it'd be possible to have the values reported directly to PLX DAQ so that there could be a real-time graph of the altitude, but I'd forgotten that PLX DAQ requires commands in the serial stream as well as the data themselves (and with just an XBee and no Stamp, there's nothing to send those commands). Of course it'd work if I put a Stamp back into the loop, and I may try that.
Tracy, am I right that they'll need to convert that byte array into a word variable somehow? What's the best way to do that? I imagine that they could take each value in turn, subtract 48 from it (as ASCII 48 is the digit 0, 49 is 1, 50 is 2, and so on), and then multiply by 1000, 100,·10 or 1, depending on the place in the array of the digit, then add the results. Is that how that kind of thing is done, or is there a more direct way? Or am I completely off base on this?
Yes, it will probably be necessary to convert to a numerical Word value, using the procedure you outlined:
convert_String2WordVar:
' enter with good array of 5 digit number as ascii string, result is number as Word
result=0
For idx=0 to 4
result = result*10 + (array(idx)-48)
NEXT
RETURN
or if time is tight, as it will be, roll it into one statement, because FOR:NEXT is slow:
convert_String2WordVar:
' enter with good array of 5 digit number as ascii string, result is number as Word
result=((((array(0)-48)*10+(array(1)-48))*10+(array(2)-48))*10+(array(3)-48))*10+(array(4)-48)
RETURN
That result could go into a window average or a low pass filter, and then to the decision about apogee. The timing will probably be tight and it may have to make due with every other or every third altitude reading. How long does it usually take for one of these rockets to reach apogee after launch?
edit: subscripts in second example were all the same due to copy and paste typo
Tracy Allen said...
Yes, it will probably be necessary to convert to a numerical Word value, using the procedure you outlined:
convert_String2WordVar:
' enter with good array of 5 digit number as ascii string, result is number as Word
result=0
For idx=0 to 4
result = result*10 + (array(idx)-48)
NEXT
RETURN
or if time is tight, as it will be, roll it into one statement, because FOR:NEXT is slow:
convert_String2WordVar:
' enter with good array of 5 digit number as ascii string, result is number as Word
result=((((array(4)-48)*10+(array(3)-48))*10+(array(3)-48))*10+(array(3)-48))*10+(array(3)-48)
RETURN
That result could go into a window average or a low pass filter, and then to the decision about apogee. The timing will probably be tight and it may have to make due with every other or every third altitude reading. How long does it usually take for one of these rockets to reach apogee after launch?
Of course that depends on the weight and drag of the rocket as well as the thrust curve of the motor, but it's·probably almost always between 5 and 30 seconds for a high power rocket. I'm seeing 10-18 seconds for my largest rockets, 15-16 pounds, 5.5" diameter, flying on K550 and K800 motors. You can't see the whole flight, unfortunately, but here's video of my first K-powered flight, a 15 pound rocket carrying a radio-control for parachute deployment:
and a graph of altitude by flight time (attached).
As far as using every third altitude reading, that shouldn't be a problem. In fact it occurs to me that with careful programming you should probably be able to avoid almost all of the timing issues by simply using fewer of the altitude reports. They certainly won't need 20 readings per second from the other sensors (for example, atmospheric gas sensors) - even one or two a second should be plenty for any reasonable purposes. The pressure-based altitude readings from the MAWD just aren't that accurate. They're great for determining apogee and an altitude for deployment of the main parachute, but they're not great for determining the motion of the rocket. An accelerometer gives far better data for that. If all they need the MAWD readings for is to detect apogee and to give a fairly good altitude reading on the way down, I don't see why they couldn't make do with (say) every 5th data point (that is, every .25 seconds), or even fewer than that. I imagine that might make the timing issues almost entirely go away, right? The only time when altitude changes very quickly is during the "up part" (ignition and the first part of coast phase), and they've already said they don't really care about those readings. During the part that they do care about, the altitude change is much slower, and I'd think that 20 readings per second would be overkill.
If I were flying a variety of sensors, the only ones I'd expect to want 20 readings/second from would be those measuring the acceleration, vibration, or rotation of the rocket. Things like temperature, CO2 levels, humidity and the like would be just fine at one or two samples per second. They may have other reasons for wanting more data, but it seems that this would be a good time for them to make a decision about how frequent they need their readings to be.
I do think that some kind of window averaging will be necessary for detecting apogee. I've had an occasional "glitch" in my data from these things in the past, and relying on a single value at a time is reasonably likely to give a false detection. Of course that will raise more issues for how frequent they need the data. If they were doing just one altitude reading per second and a five-reading window they'd likely miss several feet of readings at apogee: maybe 10-20 feet, depending upon how vertically the flight went. But a five-reading window with five readings per second seems pretty reasonable to me. The MAWD's own apogee detect algorithm probably isn't accurate to within one second on a typical flight (though not far from it).
P.S. - I think that the second version of your conversion subroutine should look more like this, right?
convert_String2WordVar:
' enter with good array of 5 digit number as ascii string, result is number as Word
alt=((array(1)-48)*1000)+((array(2)-48)*100)+((array(3)-48)*10)+((array(4)-48))
Post Edited (sylvie369) : 6/13/2009 9:04:29 PM GMT
You are right about the subscripts in the second example, I made too quick a copy and paste. I went back and corrected that. I left in the array(0), but if the altitude reading is not going to come in over 9999 (!?), then the conversion could indeed start at array(1) and save a millisecond or two. I used a formula with (((((.).).).).) such that successive digits starting at the left end up as powers of 10.
It should be possible to synchronize the readings to every Nth MAWD reading. In the following diagram, the XXXXXXX represent the message from the MAWD and the OOOO... represent the intra-message silence, and the second line is the action on the BS2 as message receiver. When synced it catches the XXXXXXX , then the subsequent PPPP.... is the processing in PBASIC, and the OOOO.... are again silent time as the SERIN awaits every other MAWD message. This depends on the PPPP.... taking a known amount of time within certain limits, otherwise it can lose synchronization. Best if the PPPP.... is a fixed time routine. (It is like synchronizing a COG with a HUB on the Propeller.) The initial SERIN has to have a good timeout value chosen to assure loss of at most one reading before it synchronizes.
**THE SERVER WONT ACCEPT THE PHOTO UPLOAD FROM HOME RIGHT NOW. I'LL SEND IT FROM SCHOOL FIRST THING IN THE MORNING...
Sylvie,
By all means, please·feel free to use·any of·these quotes or comments·in your application for promotion. What you're doing for these young rocketeers certainly meets the criteria for "Serving the Wider Community." I'm pleased to write you a recommendation on school (or Boy Scout) letterhead if you require one. Certainly you deserve the promotion!
OK, I'm stumped. I wired the MAWD to the BOE as suggested, and·as I interpreted from·the photos, with no success. I've (tried to!) attach a photo of the way we have it wired right now. I'm sure the I/O pins are all wrong, the wires are backwards, and I have resistors where I shouldn't. So I learn.
When the MAWD is turned on and the Tracy's BS2 Stamp program (attached) is run, there's no TX or RX at all. Rather than fry the BOE or the MAWD, and to circumvent hours or trial-and-error efforts (just so I can say, "Aha! I did it!", when I really didn't), I ask for help.
Help....!
Mark and the Rockteers (note: not·their fault!)
Sylvie said: Connect the ground wire (the brown one) from the cable to a VSS connector on the Stamp board, the cable's RX to one pin, and TX to another on the Stamp.
Tracy's program:
' {$BS2}
' {$PBASIC 2.5}
array VAR Byte(7)
DO · SERIN 5,84,40,escape,[noparse][[/noparse]STR array/7]···· · IF array(6)=LF THEN DEBUG STR array\7·· ' LF in array(6) means good data.
escape:
LOOP
You wrote: "I left in the array(0), but if the altitude reading is not going to come in over 9999 (!?)..."
Our projected altitude is in the neighborhood of 20-25,000 feet. The 'ASP' (BOE-MAWD payload)·will deploy and turn on 4 seconds after apogee; we anticipate that to be a minimum altitude of 15,000 feet but we want to be ready for data-capture at 20,000 feet.
We had a·fun and frustrating (for me) practice today. The upside was that two newspapers came and interviewed the kids all afternoon long. They knew how everything worked; the theory behind the project; and they were very articulate. We made especially sure to mention you guys!
The downside was that when we finally got up and running late in the afternoon-- when we had the MAWD-BOE wired-- we had no TX or RX. Nada. Nolo. Then we ran out of time and d then I couldn't get the wiring photo uploaded to you guys to troubleshoot. Bummer. I'll send·the·wiring photo·from school bright and early in the morning. Now I'll sit down to the wonderful dinner my wonderful has had waiting since 7:00 PM...!
The MAWD only transmits if it thinks it is flying. Have you rigged it up in an airtight bottle with an on/off switch on the outside, and the cable coming out as well? I'll attach a couple of photos of my setup.
As you can see, I'm just using a standard laboratory bottle washing bottle. I drilled a hole in the top and ran a rubber hose into it. I cut a couple of holes in the side to let the wires for the on/off switch and the Data Download cable to pass through: these are then tightly taped over. Inside the bottle are the MAWD itself and a 9 V battery. The bottle's lid doesn't have to be 100% airtight, though it should be close. I didn't do anything to seal around the rubber hose, for example, though·I did cut the hole a size smaller than the hose, so it expands to push against the opening.
Again, the MAWD sends nothing at all out through that serial port unless it thinks it is flying (well, other than responses to commands you might send, but I don't think you're messing with that at all). The only way to test this is to put the MAWD into some kind of relatively airtight container. You could mount it inside your payload bay, and suck on the vent ports to make it think it's flying, but you'd have to have extra holes that you don't really want in order to let the cable out the side. It's best to build a test container like I did.
In addition, you only need to connect that blue wire to one of the Stamp's I/O pins. I also attached the wire next to it so that I could (in theory) send commands to the MAWD from the Stamp, but it's not at all necessary. Two wires - the blue TX one and the brown Ground one - are all you need.
When you've got it all set up, you should be able to turn the MAWD on (using the switch you attached), and hear all of the startup beep sequence (as described in the manual: I assume you're familiar with that sequence. If not, read the MAWD manual carefully). Eventually it will stop beeping. At that point, it's waiting to launch. At that point, you suck on the rubber tube (yup. The kids will laugh like mad, but that's part of the process) to draw down the pressure inside the bottle. If things are hooked up right, you should see the altitudes scroll down your Stamp output window. When you stop sucking, they should drop to zero. It'll keep going for a while, and then stop, and then you should hear the MAWD beeping out the maximum altitude.
It should be ready to watch by the time you read this.
Sorry about the hard day, but it does sound like just a standard setback. Trust me, I went through this myself before getting it to work. And if you've got the kids understanding the project, you're working the real magic.
Re. the max. altitude thing: I'm afraid I'm the one who suggested it might not need 10,000+ feet. I went back and re-read the post at the start of the thread and see that you're going to routinely fly over 10,000 feet, so yes, you'll need all five digits. That shouldn't be an issue, though.
Post Edited (sylvie369) : 6/15/2009 2:26:43 AM GMT
The MAWD is inside·a Nalgene bottle with a tube attached so air can be drawn out. We're curious·if the BOE should blink RX or TX when the MAWD is connected (it doesn't), even though the MAWD isn't "in flight."
attahced (I hope) is the wiring. Can you check it over and offer suggestions about where we should put the wire? We're using Tracy's "simple program." Off to class. Thanks!
Mark
Comments
Here are the pictures of our 'pod' with the BOE on it and our GPS transmiter. Hope this helps. What does everyone think? What are your thoughts, observations and ideas?·Thanks again for all of your replies and help.
Sean - ARLISS Team - NH
I'm not quite sure why you're using a mosFET to turn the datalogger on and off. It's standby current is only 2ma, plenty low enough for waiting around for a couple of hours.
Post Edited (SRLM) : 6/11/2009 6:15:35 PM GMT
Sylvie, what does the telemetry look like on the capture screen? I read your interesting article. If there are say 7 bytes per altitude message, and they are emitted 20 per second at 9600 baud, that would leave about 43 milliseconds of silent time between messages, which would help the Stamp to synchronize. At 9600 baud the Stamp works most effectively with the STR modifier, and unfortunately, the WAIT or DEC modifiers are too slow. I think I picked up the 20 per second figure from SRLM's post a few back.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
·· We'll be using a shorter flash drive with lots of memory, so (physical and memory) space isn't a real concern. We also have the opposite side of the wooden board available to mount on (perhaps two BOE's...?)
The orange transmitter with the black rubber antenna is a Garmin DC 20 (DC = dog collar) transmitter. It claims a 5-mile range which we hope is ample in the Black Rock desert. They also make a DC 30 which claims 7 miles transmit distance. Our budget didn't allow for the recommended 'BigRedBee' Beeline shortwave transmittter, which claims a 35-50 mile line-of-sight range. The receiver is a Garmin Astro 220 GPS, programmed to receive a signal from the orange DC 20. Bulky, yes; affordable: barely. But it's what have to work with (and it's all my wife would allow me to spend. She said: "Be sure to keep the receipt!) Question: what should I do with the receipt if the whole apparatus drifts off into the desert, never to be seen...? I won't ask her!)
I'm intrigued by the possibility of streaming altitude data directly to the BOE/Datalogger from the MAWD like Sylvie proposed. I think it's an elegant·idea and it 'seems' within our technical grasp, with everyone else guiding us along. The students are really excited-- and a bit surprised-- by the excellent suggestions and information we've received so quickly.·Thanks! You're inaugurating some newbies into programming and electrical engineering in fine fashion!
Sylvie, please keep us up-to-the-minute, especially when you receive data on the BOE from the MAWD!
Regards,
Mark - ARLISS Team New Hampshire
There is also the current requirement of the disk itself, which in ones I have tested will be around 40 mA addition to the current drawn by the datalogger interface. The highest USB supply current (90 mA) I have seen was from a Sandisk drive that also folded up to become an SD card.
You are quite right, though. By using the SUD command, the disk itself can be turned off, down to 20 mA for the interface alone, and then WKD wakes it up. Furthermore, the SUM command turns off both the disk and the monitor interface, down to less than 2 mA. Then it takes a ping on the hardware RI line to wake it up. I don't think those capabilities are implemented in the Rocketeers' firmware and hardware, and it would certainly be worthwhile to do so if they go that route.
Personally, I favor the zero-power external switch, for a couple of reasons. For my own purposes I am usually thinking that even 2 mA is way too much. But as you point out it would not be too much for a couple of hours sitting around on a launch pad. Even if the power were less though, I like the fact that the external control avoids all problem with initialization. The drive always comes up in a known state at power up. Without that, I have found that it occasionally (and especially during development) will glitch off into la-la land, without resolution.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 6/11/2009 7:48:24 PM GMT
00040crlf
00042crlf
00046crlf
00051crlf
00055crlf
and so on. It sure looks like 7 bytes per altitude message, and yes, 20x/second with the MAWD (and that's not adjustable either). I'll play with this as soon as I have some time - maybe post a screen capture from the terminal program, and try it with a Stamp.
[color=#FFA500]' {$BS2PX} emulate transmitter ' {$PBASIC 2.5} idx VAR Word DO idx=idx+1 PAUSE 42 ' this gives about 20 per second SEROUT 5,396,[noparse][[/noparse]DEC5 idx, CR, LF] ' 7 character message at 9600 baud true LOOP[/color]' {$BS2} ' {$PBASIC 2.5} array VAR Byte(7) DO SERIN 5,84,40,escape,[noparse][[/noparse]STR array/7] IF array(6)=LF THEN DEBUG STR array\7 ' LF in array(6) means good data. escape: LOOPThe BS2 was able to keep up, although it would often take one iteration to get resynced after a reset.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I sure wish I had time this morning to do more - this is far more interesting than the meeting I'm going to.
More when I have the chance.
Edit: Woo-hoo! It seems to work with the XBee. I attached the cable to the XBee RX/TX pins (and a common ground), simulated a flight, and I see the TX light on the XBee board lighting up rapidly as the data should be transmitted. I don't have time right now to set up a receiver, but it sure as heck is transmitting something, and exactly when I'd expect it to (it sits idle until I bring down the pressure in the test bottle, so the altimeter thinks it's flying and starts sending altitude data, and then it transmits until the pressure is back to normal, then stops).
Post Edited (sylvie369) : 6/12/2009 11:10:46 AM GMT
·· This seems like a 'eureka' moment!·The output from the MAWD to the Xbee sure looks like an altitude graph when the data is graphed on Excel. But·how does the·Xbee interface with the BOE? Or would·the·MAWD-XBee set-up·be separate from the BOE? What we'd like to do is stream data from the MAWD, through the BOE, and onto the Datalogger where it will be correlated with temperature, humidity, and time·(all on one data dump from the Datalogger/flash drive to an Excel spreadsheet.)
Excellent progress; we're eager to hear even more! *And yes, I·agree with you about·about going to meetings, etc. Working on the hardware/software challenge is preferable to coming in to school (though Jess and Thomas and Sean are in my last period STEM class. Can't wait to get there!
Mark
Here's how (attached). It works. Oh baby. I removed the cable from the Data Transfer dongle, plugged it into·a MAWD whose telemetry I had already turned on. Then I connected the ground wire (the brown one) from the cable to a VSS connector on the Stamp board (I'm using a Supercarrier board instead of a BOE, but it'll work the same), and the cable's RX to one pin and TX to another on the Stamp. Then I ran Tracy's code (modified for the pins I was using and the fact that I'm using a BS2px instead of a BS2). Turn on the MAWD, let it go through the startup beeping, then suck on the tube to simulate flight, and watch the altitude numbers appear in the DEBUG terminal window. Worked perfectly. Attached is also a screenshot of the output.
Next I'll try it with a regular BS2.
Paul
Edit: Oh, it just occurred to me how to test to see if I'm missing values. Just download the data using the regular data capture software, after testing it with the BS2 and letting it record an entire "flight". That software gives all of the values, plus a convenient count of how many values were measured. I'll give that a shot too when I get a chance.
Post Edited (sylvie369) : 6/12/2009 7:10:22 PM GMT
·· This seems like a fairly simple, and elegant, solution. I just downloaded flight data from the MAWD to get a data count (1428 bits) to compare against the data/count we'll be getting from the BOE, to see if there are any missing values.
1) Now we're ready to begin surgery. There are FOUR wires on my Data Capture cable, not five: red, yellow, blue and brown. Our next step, it seems,·is·to "connect 'the middle wire' (the blue one?) to a Stamp I/O pin through a 10K resistor, then connect the brown ground pin on the cable to the BOE VSS." Is that correct?
3) After that we'll set the MAWD to do telemetry (through the Data Capture software like·you suggested.)
4) Then run Tracy's receiver program.
What do you think? Should we proceed?
Mark
You'll need to make sure that Tracy's program refers to the I/O pin that you're using. He's set up for pin 5, and for a BS2 (so if you're using a different Stamp chip you'll need to adjust that 84 to some other value, maybe). But if you use pin 5 and a BS2, you should be able to run his program "as is".
I can't wait to hear how it goes.
·· Yes, I'm eager to see how it goes, too! We have a full team practice tomorrow afternoon and these young rocketeers are·eager to dive in and make it work. I suspect we'll have to tinker and 'tweak' it a bit (adjust the 84 to another value, for example, test the wires, and teach them how to set the MAWD for telemetry.) But ultimately I see this working... maybe not tomorrow, but soon. The kids are also excited that a local newspaper is coming out tomorrow (with a photgrapher!) to chronicle their adventures. We'll be sure to give you and Tracy and our Parallax friends due credit (maybe we should send CNN your way...!)
Our next challenge after we start to receive data will be to re-write the exisiting program so the altitude data is displayed and recorded on the Datalogger with time, humidity, and temperature. This was a fun and excellent challenge last year, especially since it was all new to me and the team. Some of the rockteers are returning team members and some are newbies, a 50-50 mix of each. So the learning curve is, well, interesting!
Tracy and Sylvie, I want you to know that your mentoring has paid these kids big dividends, the first of which is the ARLISS grant we received as a direct result of last year's project. One of last year's team members, Andrew, received a $7,5OO full scholarship to Phillip-Exeter's six-week summer STEM program. Exeter is a premier New England prep·school. Also, when they returned from college visits this spring, both Mollie and Tyler (and their parents) excitedly commented that virtually every college they interviewed at wanted to hear all about their involvement in rocketry, TARC, and NASA-SLI. Together Tyler and Mollie received 8 of the 12 awards at the spring academic awards banquet. Andrew also received a full scholarship to Sant Bani school next fall, a direct result of his involvement with FIRST/Lego robotics, TARC, NASA-SLI, and now, ARLISS.
I believe in paying forward,and it seems that you and Sylvie and our Parallax friends do, too. The paragraph above describes exactly what you've helped these kids achieve, in addition to excellent learning that's not quantifiable (the opportunity to rub shoulders with NASA engineers and astronauts, for example, and to crash rockets-- and learn something from it.) Thank you for helping them learn, succeed, and move on to the next level.·I appreciate all of your time, input, and efforts.
Best regards,
Mark
Thanks for the kind words. It's extremely rewarding to read this, especially as I believe that there is almost nothing more valuable right now than giving young students real hands-on experience with risky science and engineering projects (by "risky" I don't mean dangerous, but rather "not pre-packaged so that failure is impossible"). Tracy is the one who has donated real expertise here - I'm certain that if he had a MAWD sitting in front of him, he'd have had this all working a week ago (and I believe that you got considerable help from Mike Green and SLRM as well, right?). I have spare MAWDs to play around with like this because NASA/Wisconsin Space Grant Consortium funded two of my grant applications plus two student rocketry group entries in our state contests. If anyone wants a good example of your tax dollars going to good causes, there it is.
And of course you're the one doing the heavy lifting. As I said, I've worked with student groups. It's time-consuming and sometimes frustrating, even while being so rewarding.
With your permission, though, I'd like to quote your last post in my application for promotion this fall. Right now I'm listing my rocketry, ballooning, and electronics activities as "developing scholarship", but with this I could put it as "Serves the Wider Community" as well.
==========================
I'm home again, and can verify that it's the blue wire on the MAWD cable that carries the outgoing serial data. One challenge that's in front of you still is in programming: Tracy's code reads the digits and other characters into a 7-byte array. You need to turn the first 5 bytes of that array into a word-sized value in order to do things with it mathematically (notably figure out when the altitudes are starting to drop at apogee). It'll have to be a word rather than a byte because bytes only go from 0-255, while a word-sized variable can contain altitudes from 0 to 65535 feet (which is of course higher than you're ever going to need). If you know you're never going to exceed 10,000 feet you can throw out the first byte (or maybe first verify that it's a "0"), and just work with the next four, which are the 1000s, 100s, 10s and 1s of the feet of altitude. Tracy tells us
The inability to use the DEC modifier at 9600 baud means that it may be necessary to keep using his method for reading the data. The mere "43 milliseconds of silent time" means, I think, that you'll have to do the conversion and the writing to the datalogger within 43 milliseconds. Tracy's website (see his .sig) includes this table of how long various commands take to execute:
http://www.emesystems.com/BS2speed.htm
Note that the times are in _micro_seconds, not milliseconds, so you get 43,000 of the table's units between inputs from the MAWD·to do all of your reading of data, conversion to word-sized variables, reading of other sensors, and writing to the datalogger. I think. Ask Tracy. Here is his page of valuable comments on reading serial data (including a section on reading high-speed data):
http://www.emesystems.com/BS2rs232.htm
Post Edited (sylvie369) : 6/13/2009 4:52:15 PM GMT
It looks from the first photo that you posted in this thread that you have available p3, p4, p6, p14 and p15, but not the p5 I used in my example program. Note in the photo that Sylvie posted, he used pin p15 instead of p5. Your choice. (Also observe that Sylvie posted one photo using the cool looking diagonally mounted BS2px and another using the BS2 OEM) 84 is the correct parameter for 9600 baud true on the BS2, and if that worked for Sylvie, it should work for you. The most likely alternative would be 16468, which is the parameter for 9600 baud inverted. Interested students should understand the difference between true and inverted. Let us know how it works!
There will be more learning maybe some transient frustration, and fun, to integrate this into your main program!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I used those values simply because that's what you used (Tracy) in your sample code. I'm not exactly sure what the difference between TRUE and INVERTED is. I know that in one case (TRUE, I believe), 1s are represented by a positive voltage and 0s by no voltage (or a negative voltage, in some protocols). Is that correct? And then for INVERTED it's the other way around?
But what I really need to know, I think, is how to know whether a device wants a TRUE or an INVERTED serial connection. Someone once gave me a rule of thumb, but I don't remember it.
Between transmissions, it rests at the level that represents a 1. For TRUE logic, that will be +5 Volts. Then to start a message it sends a start bit at 0 Volts, then the 8 bits of one byte, and then it goes back to the resting level +5 Volts for at least one bit period. That is called the stop bit, but it can stay at that resting level for any duration until the next byte is transmitted or received.
On old telegraph machines, the transmission was printed on a moving tape, and the pen was normally down on the paper, making a mark (drawing a line), so that was called "marking". Then when the start bit came over the wire, it would activate an electromagnet to lift the pen off of the tape, and that was called "spacing". The "marks" and "spaces" were translated into the 1s and zeros of the Baudot code or eventually to the ASCII code as we know it today. In literal sense you can look at the pen down as a physical low level that represents a logical 1. It was an INVERTED system. Most standard RS232 communication today is INVERTED, where a voltage like -10 Volts represents the mark, logical 1 and +10 Volts represents the space, the start bit, logical 0. But most microcontrollers internally use TRUE levels and send them through a hardware inverter to get to the outside world. The Stamp on its p16 DEBUG interface indeed has a hardware inverter, and the signals from p16 are always INVERTED. Is that confusing or clear?!
The bottom line is that the Stamp should be set to receive TRUE levels from the MAWK which is sending TRUE levels. Nothing bad will happen to the hardware if you mismatch the parameters. You'll just see garbage, or nothing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 6/13/2009 6:14:23 PM GMT
You will find that the number of data points reported by the MAWD Data Capture program doesn't line up correctly with the number of data points captured to the Stamp. I think that once things get going, all of the data are captured, but the telemetry output doesn't start until the altitude is over 300 feet. I've run it a few times, and that's how it seems to go: you might be on the lookout for it as well. The Data Capture program might report several altitudes of a few feet up to a couple of hundred feet at the start of the flight, but the first data point reported by the Stamp (that is, the first one sent out through telemetry) is the first point over 300 feet. After that the two data sources seem to agree just fine.
I think that this is a matter of the MAWD's firmware. Every altimeter needs some set of parameters that tell it when the rocket has launched, so it can go from "ready" mode to "flight" mode. In ready mode the altimeter simply reads the altitude, waiting for a sign that the rocket has taken off. Once it believes that the rocket has taken off, it goes into flight mode, arming the apogee detect routine. That routine detects apogee by looking for an increase in atmospheric pressure. It cannot be armed on the pad because winds and simple changes in pressure might then cause your apogee charge to go off while you're still sitting on the pad: not pretty, especially if you're still setting up the igniter.
The MAWD detects flight by looking for a rapid increase in altitude. The documentation says "160 feet above the ground reading", but I believe that it's actually 300 feet (I have a·vague memory of someone saying that the documentation is wrong on that). I may be wrong, though: it might be 160 feet, and we're losing the first value, so that the first recorded value is actually the second value after launch. I'll run some more tests to look into that. It's not that big a deal.
The documentation says that "the previous 16 altitude samples are saved to logging memory", so the Data Capture software will report at least 16 pre-launch values that are not captured in the telemetry, so the number of data points reported by the two methods will be off by that much.
I'll look·into that 300 feet vs. 160 feet thing.
EDIT:
Okay, forget about the 300 feet stuff. It seems to be 160 feet, just as the documentation say. I also seem to be losing the first data point, at least with the BS2. For example, here are the first few data from my last run:
Reported by
telemetry:··· data capture:
················ (16 prelaunch data points ending with)
·················154
················ 154
················ 174
00183········ 183
00193········ 193
00212········ 212
00222········ 222
00212·········212
00212········ 212
00212·········212
00193········ 193
(etc.)
Post Edited (sylvie369) : 6/13/2009 6:25:49 PM GMT
When (and assuming) the payload detaches from the rocket, the phone plug attaced to the rocket pulls out of the socket in the payload, completing the power circuit to the data recorder.
-Phil
Moving forward with the program, there are quite a few tasks that will have to be interleaved! There is the datalogger, the sensirion, the real time clock and decisions to be made in the program code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I actually don't think this will be a problem at all for us because our most important values will be on the way down after the rocket has already reached apogee. Will this completely solve the 160 feet problem?
By the way, this is Tyler from ARLISS NH. Thank you all for your continued support of our team.
I am not at all confident that it's reliably reporting all of the data values, though. Tracy's suggestions about adjusting the timeout values will be important.
I also just played around with using an XBee directly with the MAWD (for my own purposes: I know that won't work for you). It does work, and it's pretty slick to have nothing but the MAWD in a bottle with wires going to an XBee out in the kitchen, and to watch the reported altitudes appearing on my monitor on a computer connected to another XBee out in the living room. Unfortunately, it looks to me as though it's missing numerous values, which I find surprising. I might be wrong, though: the data captured on the receiver end always do include the value that the MAWD's memory reports as the peak altitude, and if I'm missing values, I'd have thought that one would have been among the missing from time to time.
I was hoping that it'd be possible to have the values reported directly to PLX DAQ so that there could be a real-time graph of the altitude, but I'd forgotten that PLX DAQ requires commands in the serial stream as well as the data themselves (and with just an XBee and no Stamp, there's nothing to send those commands). Of course it'd work if I put a Stamp back into the loop, and I may try that.
Tracy, am I right that they'll need to convert that byte array into a word variable somehow? What's the best way to do that? I imagine that they could take each value in turn, subtract 48 from it (as ASCII 48 is the digit 0, 49 is 1, 50 is 2, and so on), and then multiply by 1000, 100,·10 or 1, depending on the place in the array of the digit, then add the results. Is that how that kind of thing is done, or is there a more direct way? Or am I completely off base on this?
convert_String2WordVar: ' enter with good array of 5 digit number as ascii string, result is number as Word result=0 For idx=0 to 4 result = result*10 + (array(idx)-48) NEXT RETURNor if time is tight, as it will be, roll it into one statement, because FOR:NEXT is slow:
That result could go into a window average or a low pass filter, and then to the decision about apogee. The timing will probably be tight and it may have to make due with every other or every third altitude reading. How long does it usually take for one of these rockets to reach apogee after launch?
edit: subscripts in second example were all the same due to copy and paste typo
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 6/13/2009 9:12:12 PM GMT
http://faculty.alverno.edu/smithpc/K550Paul.wmv
and a graph of altitude by flight time (attached).
As far as using every third altitude reading, that shouldn't be a problem. In fact it occurs to me that with careful programming you should probably be able to avoid almost all of the timing issues by simply using fewer of the altitude reports. They certainly won't need 20 readings per second from the other sensors (for example, atmospheric gas sensors) - even one or two a second should be plenty for any reasonable purposes. The pressure-based altitude readings from the MAWD just aren't that accurate. They're great for determining apogee and an altitude for deployment of the main parachute, but they're not great for determining the motion of the rocket. An accelerometer gives far better data for that. If all they need the MAWD readings for is to detect apogee and to give a fairly good altitude reading on the way down, I don't see why they couldn't make do with (say) every 5th data point (that is, every .25 seconds), or even fewer than that. I imagine that might make the timing issues almost entirely go away, right? The only time when altitude changes very quickly is during the "up part" (ignition and the first part of coast phase), and they've already said they don't really care about those readings. During the part that they do care about, the altitude change is much slower, and I'd think that 20 readings per second would be overkill.
If I were flying a variety of sensors, the only ones I'd expect to want 20 readings/second from would be those measuring the acceleration, vibration, or rotation of the rocket. Things like temperature, CO2 levels, humidity and the like would be just fine at one or two samples per second. They may have other reasons for wanting more data, but it seems that this would be a good time for them to make a decision about how frequent they need their readings to be.
I do think that some kind of window averaging will be necessary for detecting apogee. I've had an occasional "glitch" in my data from these things in the past, and relying on a single value at a time is reasonably likely to give a false detection. Of course that will raise more issues for how frequent they need the data. If they were doing just one altitude reading per second and a five-reading window they'd likely miss several feet of readings at apogee: maybe 10-20 feet, depending upon how vertically the flight went. But a five-reading window with five readings per second seems pretty reasonable to me. The MAWD's own apogee detect algorithm probably isn't accurate to within one second on a typical flight (though not far from it).
P.S. - I think that the second version of your conversion subroutine should look more like this, right?
Post Edited (sylvie369) : 6/13/2009 9:04:29 PM GMT
It should be possible to synchronize the readings to every Nth MAWD reading. In the following diagram, the XXXXXXX represent the message from the MAWD and the OOOO... represent the intra-message silence, and the second line is the action on the BS2 as message receiver. When synced it catches the XXXXXXX , then the subsequent PPPP.... is the processing in PBASIC, and the OOOO.... are again silent time as the SERIN awaits every other MAWD message. This depends on the PPPP.... taking a known amount of time within certain limits, otherwise it can lose synchronization. Best if the PPPP.... is a fixed time routine. (It is like synchronizing a COG with a HUB on the Propeller.) The initial SERIN has to have a good timeout value chosen to assure loss of at most one reading before it synchronizes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 6/13/2009 9:34:09 PM GMT
Sylvie,
By all means, please·feel free to use·any of·these quotes or comments·in your application for promotion. What you're doing for these young rocketeers certainly meets the criteria for "Serving the Wider Community." I'm pleased to write you a recommendation on school (or Boy Scout) letterhead if you require one. Certainly you deserve the promotion!
OK, I'm stumped. I wired the MAWD to the BOE as suggested, and·as I interpreted from·the photos, with no success. I've (tried to!) attach a photo of the way we have it wired right now. I'm sure the I/O pins are all wrong, the wires are backwards, and I have resistors where I shouldn't. So I learn.
When the MAWD is turned on and the Tracy's BS2 Stamp program (attached) is run, there's no TX or RX at all. Rather than fry the BOE or the MAWD, and to circumvent hours or trial-and-error efforts (just so I can say, "Aha! I did it!", when I really didn't), I ask for help.
Help....!
Mark and the Rockteers (note: not·their fault!)
Sylvie said: Connect the ground wire (the brown one) from the cable to a VSS connector on the Stamp board, the cable's RX to one pin, and TX to another on the Stamp.
Tracy's program:
' {$BS2}
' {$PBASIC 2.5}
array VAR Byte(7)
DO
· SERIN 5,84,40,escape,[noparse][[/noparse]STR array/7]····
· IF array(6)=LF THEN DEBUG STR array\7·· ' LF in array(6) means good data.
escape:
LOOP
You wrote: "I left in the array(0), but if the altitude reading is not going to come in over 9999 (!?)..."
Our projected altitude is in the neighborhood of 20-25,000 feet. The 'ASP' (BOE-MAWD payload)·will deploy and turn on 4 seconds after apogee; we anticipate that to be a minimum altitude of 15,000 feet but we want to be ready for data-capture at 20,000 feet.
We had a·fun and frustrating (for me) practice today. The upside was that two newspapers came and interviewed the kids all afternoon long. They knew how everything worked; the theory behind the project; and they were very articulate. We made especially sure to mention you guys!
The downside was that when we finally got up and running late in the afternoon-- when we had the MAWD-BOE wired-- we had no TX or RX. Nada. Nolo. Then we ran out of time and d then I couldn't get the wiring photo uploaded to you guys to troubleshoot. Bummer. I'll send·the·wiring photo·from school bright and early in the morning. Now I'll sit down to the wonderful dinner my wonderful has had waiting since 7:00 PM...!
Regards, and thanks,
Mark
As you can see, I'm just using a standard laboratory bottle washing bottle. I drilled a hole in the top and ran a rubber hose into it. I cut a couple of holes in the side to let the wires for the on/off switch and the Data Download cable to pass through: these are then tightly taped over. Inside the bottle are the MAWD itself and a 9 V battery. The bottle's lid doesn't have to be 100% airtight, though it should be close. I didn't do anything to seal around the rubber hose, for example, though·I did cut the hole a size smaller than the hose, so it expands to push against the opening.
Again, the MAWD sends nothing at all out through that serial port unless it thinks it is flying (well, other than responses to commands you might send, but I don't think you're messing with that at all). The only way to test this is to put the MAWD into some kind of relatively airtight container. You could mount it inside your payload bay, and suck on the vent ports to make it think it's flying, but you'd have to have extra holes that you don't really want in order to let the cable out the side. It's best to build a test container like I did.
In addition, you only need to connect that blue wire to one of the Stamp's I/O pins. I also attached the wire next to it so that I could (in theory) send commands to the MAWD from the Stamp, but it's not at all necessary. Two wires - the blue TX one and the brown Ground one - are all you need.
When you've got it all set up, you should be able to turn the MAWD on (using the switch you attached), and hear all of the startup beep sequence (as described in the manual: I assume you're familiar with that sequence. If not, read the MAWD manual carefully). Eventually it will stop beeping. At that point, it's waiting to launch. At that point, you suck on the rubber tube (yup. The kids will laugh like mad, but that's part of the process) to draw down the pressure inside the bottle. If things are hooked up right, you should see the altitudes scroll down your Stamp output window. When you stop sucking, they should drop to zero. It'll keep going for a while, and then stop, and then you should hear the MAWD beeping out the maximum altitude.
Here - I made a video: http://www.youtube.com/watch?v=eHQ__-yOcYc
It should be ready to watch by the time you read this.
Sorry about the hard day, but it does sound like just a standard setback. Trust me, I went through this myself before getting it to work. And if you've got the kids understanding the project, you're working the real magic.
Re. the max. altitude thing: I'm afraid I'm the one who suggested it might not need 10,000+ feet. I went back and re-read the post at the start of the thread and see that you're going to routinely fly over 10,000 feet, so yes, you'll need all five digits. That shouldn't be an issue, though.
Post Edited (sylvie369) : 6/15/2009 2:26:43 AM GMT
The MAWD is inside·a Nalgene bottle with a tube attached so air can be drawn out. We're curious·if the BOE should blink RX or TX when the MAWD is connected (it doesn't), even though the MAWD isn't "in flight."
attahced (I hope) is the wiring. Can you check it over and offer suggestions about where we should put the wire? We're using Tracy's "simple program." Off to class. Thanks!
Mark