I thought I had taken care of replacing that last "GOSUB main2:" with a "RETURN". The way it was, with that GOSUB, would have taken the program flow via a twist of the stack back to the very beginning of the initialization sequence. I wonder that it worked at all!
Phil, Here is a thought on the Get_Data routine (Purge) routine, and I'd like your comment on this. As it stands it is,
Get_Data:
index = 0 ' Reset Index Pointer
DO ' Receive Data
SERIN RX\RTS, Baud, 100, TimeoutExit, [noparse][[/noparse]ioByte1]
buffer(index) = ioByte1 ' Add Received Byte To Buffer
index = index + 1 ' Increment Index Pointer
IF index > 14 THEN TimeoutExit ' Check For Overflow
LOOP
TimeoutExit:
RETURN
I wonder if the whole thing couldn't be replaced with,
Let the Stamp STR modifier do all the work. It does essentially the same thing as the DO LOOP, both with RTS flow control. If it works, it saves eeprom.
Mark and rocketeers,
The point of calling Get_Data before sending a command is to assure that the responses, such as "E"<CR> or "ND" can be found starting at buffer(0). Data is stored in a queue inside the flash drive, and the SERIN commands from PBASIC reads data out of the flash drive queue on a first in-first out ("=FIFO") basis. A purge simply reads out and dumps any data that may be left over in that queue, guaranteeing that the queue is empty when PBASIC sends the next command. The most important purge is the one at the start, within the loop with the "E" command, because when that is received, it means that the initialization is successful. The purge clears out extraneous data that might get there as the flash drive powers up. I think the response to the "e" is just a double check. I don't know what it accomplishes.
The point of the Check_Drive: routine is to verify whether or not a memory card is attached.
-- The viable responses are ">" for yes or "ND" for "no disk". I don't know why the "DD" response was in the PBASIC code. That is not a viable response listed in the Vinculum documents.
-- Mark, there should be no call for a 5 second pause in that routine. If anything, that pause should be at the top or absorbed in the "E" handshake routine. If the program only works with that 5 second pause there, I think it must have to do with a problem in the earlier initialization.
-- If there is no disk, there is no point in trying to log data.
Mark, The BS2pe would pop into the same socket as the BS2, and there would be no hardware changes or firmware changes, except the many you still need to do to make the mission accomplished. You can still do a lot with the BS2--There is no need to get a '2pe unless you anticipate a lot of additional programming or unless you want to ditch the flash drive and log the data right in the Stamp eeprom instead.
I tried the code mod you suggested in a program I'm running that
uses the Parallax Memory Stick Datalogger.
It hangs at the first call to Get_Data in the Vinculum initialization section
where an 'E' is sent since the variable 'index' never got bumped up from
zero.
That fixed it. Then I tried going back to your version, omitting the
index = 1 statement following the TimeoutExit label. Plus I revised
the synchronization section to read
' For Synchronization send E until echoed back
'DO WHILE (index < 1)
PAUSE 250
SEROUT TX\CTS, baud, [noparse][[/noparse]"E", CR] ' Transmit "E CR"
GOSUB Get_Data ' Get Returned Data
'LOOP
GOSUB Purge ' Purge Buffer of leftover junk
so that it was no longer a loop.
That resulted in another hang in the Check_Drive loop. Never exited
from that loop.
So, your modification works, but only if 'index = 1' is added after the
Timeout_Exit label.
The routine using the STR modifier does not advance the PBASIC "index" pointer. That is handled internally by PBASIC. The loop to test for response to "E" would have to be something like this:
DEBUG "Top",CR
GOSUB Get_Data ' purge flash drive buffer
DO
PAUSE 128 ' wait about 1/8 second
SEROUT TX\CTS, Baud, [noparse][[/noparse]"E", CR] ' Sync Command Character
GOSUB Get_Data ' Get Response/purge
LOOP UNTIL buffer(0)="E" AND buffer(1)=CR
That is a stronger test, because it requires the response to be actually "E" followed by CR, as shown in the Vinculum documenetation. There is also a c program ("vHello.c, also VPIC-Hello.mcp) available along with the app notes on the Vinculum web site that does it that way, namely, to insist that the last two characters in the buffer are "E" and $0D. Just requiring that any old thing at all be received in the buffer is not a very strong test. The PBASIC variable "index" becomes superfluous. There does certainly have to be a call to Get_data to purge out garbage in the flash drive buffer.
If that didn't work, my first approach for debugging would be a little routine that stuffs zeros in the Stamp 14 buffer bytes, and then after the command, goes back and prints out the hex values it finds there.
I reentered your 'stronger' test for 'E' plus a carriage return, again
using the STR modifier in your new Get_Data subroutine with no
reference to index beneath the TimeoutExit label
Everything works as advertised very consistently this time.
Thanks for suggesting the stronger test.
Even though you didn't show it, I added the same code to the test
for 'e' plus a carriage return. Nothing broke.
I recommend that the rocketeers incorporate this feature into their
program.
My problem earlier was related to the fact that the layout of my variable
declarations is different than theirs and I had to do a bit of translation.
phil
Post Edited (phil kenny) : 2/24/2008 11:19:41 PM GMT
· Great question! Exactly·where IS the power coming from that makes the green light on the Paralalx board 'blink' one time when we switch the robot from '0' to '2'. ····· I can only guess, but I know where it ISN'T coming from: any power supply (battery, 9-volt adapter, etc.) The robot does not have any power input when the light blinks...!
I seem to recall that a capacitor (?) stores electricity? Is that right? Is there a capacitor on the Parallax board that maybes stores enough power to make the green light blink?I can only speculate (or postulate, or ruminate....!)
·We downloaded and ran ' Rocketeers_tta080223.BS2··' at practice today,·but it ran 'rough'. I've gather from the posts that appeared after we downloaded it earlier today that·it has some bugs in it. I'll try and decipher them, and·then cobble the program together and run it again.
At practice today, and in the interim, we used Rocket_Robot_February_21.bs2. It·initialized and ran directly from the robot every time, with 100% success! We only have one real robot. Andrew is it's caretaker and·its name is Phidippiedes. Tim, Tyler, and I have Parallax boards with servomotors attached. I'm working on buildng another robot as 'spare time' allows but·finishing·the rest of the rocket takes priority.
Andrew·started formally ground testing the robot to demonstrate 'proof of concept.'·He then downloaded the data he captured as the robot maneuvered across my living room and basement floor, and he's already writing a draft of his section of the Flight Readiness Review report (thanks to you.) Andrew, why don't you give everyone a brief update?
Is anyone interested in joining us at Marshall Space Flight·Center for the launch and deployment of OUR robot on April 23-27? The actual launch day is Saturday, April 26th, but·there's a 'rocket fair' (science fair-type·displays)·and tours of MSFC the few days before the launch.
Thanks for your posts! I have my work·cut out for me this evening, figuring out where to put the debugs. But we're up and going, and that's HUGE progress.
·· That's a question I·can't answer. The 15*60 command line came with one of the earlier versions of the program (a few pages back). We've been adjusting 'pause' lengths to adjust how fast the data is logged; currently it's about one per second. This is one of the bigger problems in our mission right now because the robot will be logging data as it descends. The·DataLogger measures 10 samples and then the robot's treads run·for 'X' seconds (Andrew, how long do the treads run for?)
Today we timed how long it takes for the robot to initialize and then·start recording data after the nylon dowel pin is pulled, to power up the robot. It takes 18 seconds (Andrew, please confirmthis.)· It cycles through data sampling and ground movement subroutines as it descends, leaving 'holes' in the data (especially from deployment to T-plus 18 seconds, the longest gap.) At this point we're not sure exactly how we're going to correlate flight time with Datalogger·samples. We do have two altimeters/accelerometers on board that record total flight time and flight events.
Mollie, our Student Project Lead,·asked a practice today, "How simple (or complicated) would it be to simply have the program run a timer and record total elapsed time (along with the temperature and humidity data?)" We could compare this time with the altimeters' flight time to understand exactly when, and at what altitude, the samples were collected at. That's ultimately what our mission is.·I·replied that I'm sure it's possible (since Andrew and I figured out how to show how many times the servos·cycle)·but time is not on our side at this juncture. It seems like yet another layer of (complicated?) programming, and our BS2 stamp's memory (and mine!)·is nearly full. If it is indeed possible (given the time we have), then we could buy a couple of BS2pe's. That's why I asked Tracy·earlier if we can 'expand' the memory.
Keeping Occam's Razor in mind, what's the best, and simplest·way, to correlate flight time with program run time? What are other options?
I've done a bit more experimenting with the Vinculum initialization sequence
in the Memory Stick Datalogger. Using the following code:
' Send 'E' to start the synchronization process.
' Expect 'E' and a CR for the response
DO
PAUSE 128 ' wait about 1/8 second
SEROUT TX\CTS, baud, [noparse][[/noparse]"E", CR] ' Sync Command Character
GOSUB Get_Data ' Get Response/purge
LOOP UNTIL buffer(0)="E" AND buffer(1)=CR
GOSUB Get_Data ' Purge Buffer of leftover junk
I observed that the program began writing data to the SD card immediately
after downloading the code to the Stamp. No hangups at all. However, turning
the Stamp power off and then back on reproduced Mark's earlier symptom of no
data written to the SD card unless the RESET switch is pressed.
The code was in an infinite wait loop, never seeing 'E' and CR from the Vinculum.
Changing the code to:
' Send 'E' to start the synchronization process.
' Expect 'E' and a CR for the response
DO
PAUSE 250 ' wait about 1/4 second <<======
SEROUT TX\CTS, baud, [noparse][[/noparse]"E", CR] ' Sync Command Character
GOSUB Get_Data ' Get Response/purge
LOOP UNTIL buffer(0)="E" AND buffer(1)=CR
GOSUB Get_Data ' Purge Buffer of leftover junk
resulted in the correct operation of the Memory Stick Datalogger.
It passed thru the loops for getting 'E' plus CR and 'e' plus CR with
no problem. That slightly larger delay made all the difference.
Powering off and on no longer affected the operation.
I can only conclude that the Vinculum is quite sensitive to the delays
introduced by the PAUSE statements.
Hopefully, this info will be useful to the rocketeers and perhaps others.
phil
Post Edited (phil kenny) : 2/25/2008 5:57:06 PM GMT
That is very useful Phil. In the Vhello.c code, after sending the "E"<CR>, it goes into a loop with 100ms pauses waiting for the serial buffer to receive back at least two characters. In that code, the serial buffer is autonomous and interrupt driven, so they can test how many chars have been received. When at least two have been received it discards all but the last two, and tests if those are "E"<CR>. Maybe it just takes a while for the drive to send back the response.
Subsequently, does your program have any problem with the check_drive routine, Phi? In particular, does it need anything like the 5000 millisecond delay that the rocketeers have noted? I am wondering about the 18 second (?!) delay from startup to taking data that Mark reported, where that is coming from.
Rocketeers, in the program, "Rocket_Robot_February_21.bs2", the movement sequence ended with a GOSUB main2, where main2 was the top of the program. That would start it over from the beginning, through all the initialization and delays. It might run, and one can't complain about success, but it does need work on the program structure. Taking a program back to the top with a GOSUB is not a good programming practice.
No extra delays were in the check_drive routine. It was the same as
in your Rocketeers_tta080223.bs2 file, except that I had a PAUSE 100
in there where you used PAUSE 1. I'll test it later today and make sure
that it still runs with PAUSE 1 in place of PAUSE 100.
I haven't timed the total delay in my program from power on until
data begins to get written to the SD card, but it is between 6 and 10
seconds.
On my board there are red and green LED indicators that get lit when
the SD file is closed and opened, respectively, so I can see what's really
happening after the Stamp is no longer connected to a PC.
My guess is that Mark is measuring the 18 seconds based on when
the robot tread starts to move. He doesn't really have anything else
to tell that he isn't stuck in a loop.
One reason I installed the file open/closed LEDs was to know when
it is safe to turn off power to the Stamp. Removing power when the
data file is open can leave the stored data corrupted.
I revised my Check_Drive routine to exactly match yours, including
the PAUSE 1 statement and there was no problem with the program
hanging up on a cold start from the power off state.
I did, however, still need the PAUSE 250 statement in the loop that
checked for 'E' plus CR in the Vinculum initialization code. When that
was dropped to PAUSE 128, the code hung on a cold start. Only hitting
the RESET switch got it moving along and storing data to the SD card.
I have a DEBUG statement in my code to show when each write to the
data file takes place as well as the data actually being recorded.
Perhaps Mark could include something similar and get a better handle
on the true time it takes to begin logging data, instead of relying on
the robot tread movement as an indicator.
I have a better number for the time to start logging from a cold start.
It is 7 seconds with the PAUSE 512 and PAUSE 2048 statements that
take the Vinculum out of its RESET condition.
··· Phil's right: the 18 seconds is measured from a 'cold' start-up until the robot starts moving. Here's the run-down:
Time = 0: Power on - The nylon pin is pulled from the jack mounted on the robot.
T +1 ---> 8 seconds: The Datalogger and flash drive synchronize. The Datalogger light goes red; the light·in the flash drive blinks rapidly. *There is a 5 second [noparse][[/noparse]PAUSE 5000] command in·this version of the·program (Rocket_Robot_February_21.bs2).
T +9 ---> 18 seconds: The sensor measures, and the Datalogger records, 10 samples.
T +19 ---> 23 seconds: The program cycles back through to the beginning and the Datalogger records data·(quicker this time because the Datalogger and flash drive don't have to re-initialize.) The ground movement subroutine kicks in; the robot moves; and the sequence repeats... again, and again, and again (which is GOOD!)
I've enjoyed reading and trying to figure out the flurry of posts between you and Phil the last day or so.·It's waaaaaaaaaaaaaaay over my head right now············· and·so I've held·off·on cutting-and-pasting·any more·debugs into the program for now (waiting·for the electronic dust to settle...!) I was with you (somewhat) up until 5 or 6 posts ago; then the program started doing just what Phil describe.
I hope you guys·don't feel like I'm 'slacking' in any way, but there's not much I can offer in the way of professional dialogue. I don't even want·to presume that I have a valid suggestion, and I certainly don't want to come across as a prima donna (prima marko?) So I sit aside, humbly, with hat in hand...
We ARE learning tons, guys·(on a relative scale at least), so don't give up on us now. This is too much fun, and it's a great education!
Thanks;Mama K says it's dinner time!·(veggie burgers for dinner, with ketchup, lettuce, and relish. I relish them.
>··· )
·· You wrote: "Removing power when the data file is open can leave the stored data corrupted." ~ SLI Team members take note! ~
This is good to know ("Now ya tell us...!") · I'm surprised we haven't fried a Parallax board(or two,or three), BS2 stamp, flash drives, etc. yet, with all the plugging in and unplugging we do. Have you ever sat around the table with 6 or 7 excited kids (total flurry of hands in the mix·= 12-14, not including mine! Average = 13 hands.) Once the robot started moving and logging data, and once the kids started writing program code, EVERYONE wanted to be part of the 'hands-on' learning... which included plugging things in at just the right (or wrong) moment!
Mollie, our Student Project Lead, asked a practice today, "How simple (or complicated)
would it be to simply have the program run a timer and record total elapsed time
(along with the temperature and humidity data?)"
Since no one has commented on this yet, I'll take a shot at it. However, Tracy
can give a much better answer since data logging is the business his company
specializes in.
Most data logging applications use a battery backed up Real Time Clock (RTC).
These gadgets, once the time of day has been set, keep fairly accurate time, even when power is shut off. One such device is:
It requires a little soldering to get the signals and power connected, plus a small
battery. The price is pretty reasonable at $20 each.
They do need some code to function in a Stamp, but example programs are
readily available. What might not be available is enough free space in your
program with the existing BS2 Stamp. As Tracy mentioned, there are other
versions of the Stamp that can support larger programs. These would include
the BS2pe that he favors.
The other big factor weighing in against incorporating an RTC is the deadline
for launch. At some point before then you'll have to freeze the design of both
hardware and software and focus on final test.
Taking advantage of the extra code space in the other slots is a non trivial
programming activity, especially for folks just getting used to programming
the BS2 Stamp.
Maybe I've opened another can of worms by even mentioning the RTC, but if it
really is necessary to include a time stamp with each record stored in the
Memory Stick Datalogger, this is one approach. Capturing a stream of data
points without the time, greatly decreases the value of doing it.
·· You make two good points (rather, point and counter point):
1) "At some point... you'll have to freeze the design of both hardware and software...:
Point well made, and well taken... and I think we're nearing the 'freeze'·point. We're slated to make an hour-long video teleconference with NASA on March 31st. A week before that (March 24th) we have to post our Flight Readiness Review report on our website (www.wearerocketry.org) so NASA engineers can peruse it before the students present to them. Posting the report to the website assumes that it's been written, which assumes that we are, 'flight ready.' I've asked Mollie, our Student Project Lead, to have the final draft of the FRR report in my hands a week before we post it so I can review it (to me by March 17th.) SHE has asked all the Subsysytem Team Leads (robot, rocket, recovery, etc.) to have their·sections written and to her by March 12th. That assumes that all the hardware and software work is done... You get (and made) the point: we're nearing the freeze point, and the freeze point is·a little more than·two weeks away.·
2) "Capturing a stream of data points without the time, greatly decreases the value of doing it."
Again, point well made and well taken (are you reading this, SLI Rocketeers...?) Why measure and record data if·we can't correlate it with altitude, which is our primary mission.·You feel our angst! Therein lies today's problem...· We have considered measuring flight time-- from liftoff to robot touchdown-- with a digital watch, then·comparing what we get·to the times/altitudes recorded by the on-board altimeters. Crude, but better than nothing.·We're open to (two week, low-tech, low cost) solutions!
The idea of using·an RTC seems enticing (somehow, in the same way that standing next to a cage full of tigers seems 'enticing'...!)·UnfortuntelyIfear that we might well get side-tracked and never·finish·the·RTC 'job'·(and, we only have two weeks for ordering, shipping, engineering, programming... and other parts of the rocket to finish, and a report to write.)·I'd rather the students learn to do·one, or several things well rather than fast (as they're doing with the robot and the programming.) Yes, we do have a 'mission'. But·keep in mind that the project, the·rocket, and the robot are designed to be the literal vehicles for a bigger mission:·knowledge. At this juncture I'd say, "Mission accomplished!" (*but I still want to see the rocket fly, the robot landsoftly and safely, and get good data!)
Mark, I think it was Phil who warned, "Removing power when the data file is open can leave the stored data corrupted", but I will second that caveat! Many hands make short work, and/or too many cooks spoil the pizza!
You commented that you and your team are as we speak using the program, "Rocket_Robot_February_21.bs2", but the most recent one I can find posted is "Rocket_Robot_IT_RUNS_February_21.bs2". Is that the same thing? We all need to be on the same page!
· Same thing (same program, same page): We're currently running "Rocket_Robot_IT_RUNS_February_21.bs2". What's your read on the 'time' predicament? (see Phil's, and my, last posts.) Phil made a good point when he said, "At some point... you'll have to freeze the design of both hardware and software." I think includes integrating a Real-Time Clock
I've also·heard that "Many hands make light work." How true! These kids are learning a lot about the importance and value of teaming and team building. As a Boy Scout leader I emphasize to the patrol leaders (a patrol is a group of 6-8 Scouts) that they should find each Scout's strengths, then delegate accordingly. I also encourage them to know their own limitations and learn when to reach out for assistance from other patrol members or adult leaders. Some Scouts know how to tie knots very well, and some don't. Some are excellent·with first aid, while others·would hurt themselves putting on a band-aid. Likewise with computer programming. You guys are the experts.
··Attached is·the version of the program we're currently running: "Rocket_Robot_IT_RUNS_February 21, 2008.bs2. I previously·deleted·a few·of the 'commented out' comments, but it's largely unchanged since it was first posted.
Sorry I haven't been on the forum, the internet at my house has not been working very well. The answer to your first question (Andrew, how long do the treads run for?)... The treads run for about 40 seconds, capture 3 data packets, run for 40 more seconds...
The answer to your second question (how long it takes to initialize from pulling the pin)... It takes about 15 seconds to initialize using my flash drive..
-Andrew
(I also have completed·a rough draft of·3 trials with the robot, and they are attached to this post)
·· Your trials, and your preliminary reports are a good start. You're maybe·halfway there and I would expand on them as suggested below.·I also like the idea of adding a clock on the robot. But is it fesaible? If not, what'sor best option? We do need to corrleate the data with flight time and altitude somehow...
Explore options·and solutions with Mr. Allen and Mr. Kenney; learn from them. And be sure to read the last three or four posts about adding an RTC (Real-Time Clock). We've already discussed some of the problems and limitations. Maybe our best solution is non-robotic...
Here are a few suggestions for your part of the FRR report:
1) Include the date, time, location (including city and state), and duration of all trials.
2) Write more comprehensively. Explain everything that happened: clearly, concisely, and thoroughly. "Paint" a very clear picture with words.
3) Consider including a (line) diagram of where the robot traveled during each trial as we discussed on Sunday. You could do this on the computer from·the hand-drawn sketches you made during the trials, to give it a more·professional appearance in the report.·This helps the reader visualize what happened even better.
4) Consider adding the 'raw' data (the Excel series of temperature and humidity readings) as 'Appendum A, B, anc C'·at the end of the FRR report.
5) Be sure to give everything a proper label and title (you can do this with the 'legend', etc. right on Excel)
6) What about including the total distance the roboto traveled, the total time of travel, and the lateral distance from the 'touchdown' spot (like we measured in the basement at my house?) Would calculating the robot's velocity (speed) be useful. Or would it just be extra, non-essential information. I would include the distances·and direction traveled·in your·diagrams.
7) Pictures, pictures, pictures! of the robot in action, and of the three different terrains. Include these in the FRR report.
8) Review our FRR report from last year (on the NASA SLI weblink,and on our website); review other team's FRR reports, too. Read NASA's FRR report requirements before you finalize your part(s) of the report.
9)·Finally, re-check everything for accuracy. You are a NASA contractor, and this is precision, NASA-quality work. Aristotle, I believe, said, "We are what we repeatedly do. Excellence then, is a habit, not an act."
Is there anything else that you can think of that we need to do on the robot? What about making a 'shell' that fits over it, to go on top of·the plastic static guard material? It would have to fit inside the·phenolic robot 'capsule' you have (the one with the string and the pin inside.)
I'd like to continue the discussion of the ins and outs of the flash drive with Phil, but I think we will move that to another thread. It is tangential to the subject of the rocket mission.
On the subject of the real time clock. An RTC chip like the DS1302 would add a lot of value to your system and to your data. The RTC is an 8 pin chip that would plug into your white block protoboard on your BoeBot, and connect to power and a couple of the free Stamp signal lines. The chip also requires a 32kHz watch crystal, which would be soldered right to the two crystal pins on the chip, and a couple of capacitors. Here are considerations:
1) Is there room to fit it physically? Looking back at a photo posted earlier in this thread, I see that you have the white breadboard largely occupied by the flash drive interface and the Sensirion. Can you move those over to free up space for an 8-pin chip?
2) Do you have three unused signals pins from the Stamp? The DS1302 needs to use three i/o lines, plus Vss and Vdd. I think you do. From your program, I see the following:
That accounts for 6 pins, and two more are used (p14 and p15) directly for the servos. So that by my count leaves 8 pins unused. Is that right?
3) Is there room in the program to add more code? Well, the program you are using now occupies 99% of the available eeprom, and only 19 bytes are left unused. However, as has been pointed out several times here, you can reclaim a lot of that space by eliminating or tightening up the DEBUG statements. For example, the 5 DEBUG statements at the top of the program occupy 20% of the eeprom:
DEBUG CLS, CR
DEBUG "John Stark Regional High School, NH", CR, CR
DEBUG "NASA Student Launch Initiative Rocketry Team", CR, CR
DEBUG "Humidity Data Acquisition and Robot Movement Program", CR, CR
DEBUG "______________________________________________________", CR, CR, CR
During the flight, who is going to read that? A simple DEBUG "top!" should be sufficient (and necessary) for debugging. There are many other things that can be done to reclaim space too, but I won't get into those here. Even the 20% reclaimed would be enough to add the code necessary for the RTC.
4) Do you have enough in your budget for the RTC? A DS1302 + 32768 Hz crystal cost $7.25 from Parallax.
5) Do you have time to incorporate it? There is plenty of help here if you are willing to do the work. I'd suggest you stick with and work within the constraints of the BS2 and not attempt to change over to a BS2pe.
· The robot's 'shell' has to be nearly pancake flat because it has to fit inside a 4" diameter rocket/tube. That's 4" from side-to-side, leaving little wiggle room. The treads extend 1/2" each beyond the edge of the Parallax board, which is 3" wide (total width is right at 4".) The treads, spacers, and Parallax board are a little over 2" high. That leaves maybe an inch or so for the 'shell'. I was visualizing something like·a calculator's·hard case, etc... nothing fancy-schmancy, just enough of a shell to add one more layer of protection. A colorful protective shell·sounds nice! (assuming the shell fits.) The robot is a little longer than a Parallax board, and I think Andrew posted photos a few pages back. Let·us know what you have in mind!
··You ask some valid questions and make some good points:
Do you have enough in your budget for the RTC? - A DS1302 + 32768 Hz crystal cost $7.25 from Parallax.
The answer there is, "yes" (just barely)
Is there room to fit it physically?
Ibid: The answer there is, "yes" (just barely)
Do you have time to incorporate it? There is plenty of help here if you are willing to do the work.
That's more difficult to answer, and the answer is "yes" and "no". If you recall·the timeline I posted earlier today, we only have two weeks or so left before the Flight Readiness Review (FRR) to get EVERYTHING done. That includes a lot: writing and posting the Flight Readiness Review (FRR); making·and posting·an FRR PowerPoint presentation; finishing the second Parallax-PASPort module (the ASP) that mounts inside the nose cone; hardwiring everything and bench testing it; ground testing everything; and regular classes. While my heart says, "Go for it" my experience says,"Uhhhhhh... think before you leap."
One·point I·don't believe·that I've made clear is that none of these student rocketeers·are in the same school builidng·I'm in!·That complicates things, especially the hands-on work. Three attend classes at the local high school, one is in prep school 2 hours away, one is home schooled,·and·one lives and goes to school nearly an hour away. Four of the six were former students of mine in middle school; two, including my son,·were on a robotics team I·mentored a few years back.
We meet once a week on Sunday afternoons to do all the hands-on work, then scatter like seeds to the wind after practice. We try as hard as we can to stay in touch by e-mail and the forum during the week, but sometimes that's just not enough time. Reality is what reality is, and we try to do as much as we can.
With that said, and in good faith, I'll go ahead and order·a DS1302 + 32768 Hz crystal from Parallax.···· But we will need lots of guidance in installing it, as much as (or maybe more than) we've needed all along. Thanks, and kudos to you guys for hanging with us this long! I think young Andrew will be thrilled when he hears about this. He isn't sure what to do with his eager hands and bright young mind now that the movement and datalogging subroutine are nearly written and operational. He asked yesterday, "What do you want me to do next?" I guess we just found an answer for him!
I'm going off-line to place an order to Parallax. With any luck it will get here before Saturday.What's another 20 bucks at this point anyway?!
·· I just placed·the order for a·Parallax·DS1302·and 32768 Hz crystal that Tracy suggested. With three day shipping, it should be here·on Friday...~ !Yippee!··
Andrew and Tim, please start reading the 'tech specs' (technical specifications) for the Parallax DS1302 RTC (real time clock) so that you're familiar with it before Sunday's practice. Be sure to print out the instructions and schematic drawings·for how to wire it into the robot's PCB (printed circuit board.) Andrew, you'll start there on Sunday. Consider asking questions ahead of time so we can dive right in.
Comments
I thought I had taken care of replacing that last "GOSUB main2:" with a "RETURN". The way it was, with that GOSUB, would have taken the program flow via a twist of the stack back to the very beginning of the initialization sequence. I wonder that it worked at all!
Phil, Here is a thought on the Get_Data routine (Purge) routine, and I'd like your comment on this. As it stands it is,
Get_Data: index = 0 ' Reset Index Pointer DO ' Receive Data SERIN RX\RTS, Baud, 100, TimeoutExit, [noparse][[/noparse]ioByte1] buffer(index) = ioByte1 ' Add Received Byte To Buffer index = index + 1 ' Increment Index Pointer IF index > 14 THEN TimeoutExit ' Check For Overflow LOOP TimeoutExit: RETURNI wonder if the whole thing couldn't be replaced with,
Let the Stamp STR modifier do all the work. It does essentially the same thing as the DO LOOP, both with RTS flow control. If it works, it saves eeprom.
Mark and rocketeers,
The point of calling Get_Data before sending a command is to assure that the responses, such as "E"<CR> or "ND" can be found starting at buffer(0). Data is stored in a queue inside the flash drive, and the SERIN commands from PBASIC reads data out of the flash drive queue on a first in-first out ("=FIFO") basis. A purge simply reads out and dumps any data that may be left over in that queue, guaranteeing that the queue is empty when PBASIC sends the next command. The most important purge is the one at the start, within the loop with the "E" command, because when that is received, it means that the initialization is successful. The purge clears out extraneous data that might get there as the flash drive powers up. I think the response to the "e" is just a double check. I don't know what it accomplishes.
The point of the Check_Drive: routine is to verify whether or not a memory card is attached.
-- The viable responses are ">" for yes or "ND" for "no disk". I don't know why the "DD" response was in the PBASIC code. That is not a viable response listed in the Vinculum documents.
-- Mark, there should be no call for a 5 second pause in that routine. If anything, that pause should be at the top or absorbed in the "E" handshake routine. If the program only works with that 5 second pause there, I think it must have to do with a problem in the earlier initialization.
-- If there is no disk, there is no point in trying to log data.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 2/24/2008 7:51:38 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
uses the Parallax Memory Stick Datalogger.
It hangs at the first call to Get_Data in the Vinculum initialization section
where an 'E' is sent since the variable 'index' never got bumped up from
zero.
Modifying your code just a bit to read:
That fixed it. Then I tried going back to your version, omitting the
index = 1 statement following the TimeoutExit label. Plus I revised
the synchronization section to read
so that it was no longer a loop.
That resulted in another hang in the Check_Drive loop. Never exited
from that loop.
So, your modification works, but only if 'index = 1' is added after the
Timeout_Exit label.
Good idea to use the STR modifier.
phil
I'll have to look into why it seemed to work for a while, then quit.
The problem with your mod to the Get_Data subroutine using the
STR modifier is that the Check_Data routine never gets the '>' character.
Still don't know why it seemed to work once.
phil
Post Edited (phil kenny) : 2/24/2008 8:59:34 PM GMT
The routine using the STR modifier does not advance the PBASIC "index" pointer. That is handled internally by PBASIC. The loop to test for response to "E" would have to be something like this:
That is a stronger test, because it requires the response to be actually "E" followed by CR, as shown in the Vinculum documenetation. There is also a c program ("vHello.c, also VPIC-Hello.mcp) available along with the app notes on the Vinculum web site that does it that way, namely, to insist that the last two characters in the buffer are "E" and $0D. Just requiring that any old thing at all be received in the buffer is not a very strong test. The PBASIC variable "index" becomes superfluous. There does certainly have to be a call to Get_data to purge out garbage in the flash drive buffer.
This is without PBASIC variable "index":
If that didn't work, my first approach for debugging would be a little routine that stuffs zeros in the Stamp 14 buffer bytes, and then after the command, goes back and prints out the hex values it finds there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 2/24/2008 9:11:11 PM GMT
using the STR modifier in your new Get_Data subroutine with no
reference to index beneath the TimeoutExit label
Everything works as advertised very consistently this time.
Thanks for suggesting the stronger test.
Even though you didn't show it, I added the same code to the test
for 'e' plus a carriage return. Nothing broke.
I recommend that the rocketeers incorporate this feature into their
program.
My problem earlier was related to the fact that the layout of my variable
declarations is different than theirs and I had to do a bit of translation.
phil
Post Edited (phil kenny) : 2/24/2008 11:19:41 PM GMT
· Great question! Exactly·where IS the power coming from that makes the green light on the Paralalx board 'blink' one time when we switch the robot from '0' to '2'. ··
I seem to recall that a capacitor (?) stores electricity? Is that right? Is there a capacitor on the Parallax board that maybes stores enough power to make the green light blink?I can only speculate (or postulate, or ruminate....!)
Mark
·We downloaded and ran ' Rocketeers_tta080223.BS2··' at practice today,·but it ran 'rough'. I've gather from the posts that appeared after we downloaded it earlier today that·it has some bugs in it. I'll try and decipher them, and·then cobble the program together and run it again.
At practice today, and in the interim, we used Rocket_Robot_February_21.bs2. It·initialized and ran directly from the robot every time, with 100% success! We only have one real robot. Andrew is it's caretaker and·its name is Phidippiedes. Tim, Tyler, and I have Parallax boards with servomotors attached. I'm working on buildng another robot as 'spare time' allows but·finishing·the rest of the rocket takes priority.
Andrew·started formally ground testing the robot to demonstrate 'proof of concept.'·He then downloaded the data he captured as the robot maneuvered across my living room and basement floor, and he's already writing a draft of his section of the Flight Readiness Review report (thanks to you.) Andrew, why don't you give everyone a brief update?
Is anyone interested in joining us at Marshall Space Flight·Center for the launch and deployment of OUR robot on April 23-27? The actual launch day is Saturday, April 26th, but·there's a 'rocket fair' (science fair-type·displays)·and tours of MSFC the few days before the launch.
Thanks for your posts! I have my work·cut out for me this evening, figuring out where to put the debugs. But we're up and going, and that's HUGE progress.
L-8-R, G-8-R,
Mark
The comment in the constant definition section of your program says
From this I gather that you expect to log a sample once per second.
Yet nowhere do I see anything that controls the actual sampling interval.
Nor do I see this constant being used anywhere.
How do you plan to gather data at exactly one sample/second?
phil
·· That's a question I·can't answer. The 15*60 command line came with one of the earlier versions of the program (a few pages back). We've been adjusting 'pause' lengths to adjust how fast the data is logged; currently it's about one per second. This is one of the bigger problems in our mission right now because the robot will be logging data as it descends. The·DataLogger measures 10 samples and then the robot's treads run·for 'X' seconds (Andrew, how long do the treads run for?)
Today we timed how long it takes for the robot to initialize and then·start recording data after the nylon dowel pin is pulled, to power up the robot. It takes 18 seconds (Andrew, please confirm this.)· It cycles through data sampling and ground movement subroutines as it descends, leaving 'holes' in the data (especially from deployment to T-plus 18 seconds, the longest gap.) At this point we're not sure exactly how we're going to correlate flight time with Datalogger·samples. We do have two altimeters/accelerometers on board that record total flight time and flight events.
Mollie, our Student Project Lead,·asked a practice today, "How simple (or complicated) would it be to simply have the program run a timer and record total elapsed time (along with the temperature and humidity data?)" We could compare this time with the altimeters' flight time to understand exactly when, and at what altitude, the samples were collected at. That's ultimately what our mission is.·I·replied that I'm sure it's possible (since Andrew and I figured out how to show how many times the servos·cycle)·but time is not on our side at this juncture. It seems like yet another layer of (complicated?) programming, and our BS2 stamp's memory (and mine!)·is nearly full. If it is indeed possible (given the time we have), then we could buy a couple of BS2pe's. That's why I asked Tracy·earlier if we can 'expand' the memory.
Keeping Occam's Razor in mind, what's the best, and simplest·way, to correlate flight time with program run time? What are other options?
Thanks,
Mark
I've done a bit more experimenting with the Vinculum initialization sequence
in the Memory Stick Datalogger. Using the following code:
along with
I observed that the program began writing data to the SD card immediately
after downloading the code to the Stamp. No hangups at all. However, turning
the Stamp power off and then back on reproduced Mark's earlier symptom of no
data written to the SD card unless the RESET switch is pressed.
The code was in an infinite wait loop, never seeing 'E' and CR from the Vinculum.
Changing the code to:
resulted in the correct operation of the Memory Stick Datalogger.
It passed thru the loops for getting 'E' plus CR and 'e' plus CR with
no problem. That slightly larger delay made all the difference.
Powering off and on no longer affected the operation.
I can only conclude that the Vinculum is quite sensitive to the delays
introduced by the PAUSE statements.
Hopefully, this info will be useful to the rocketeers and perhaps others.
phil
Post Edited (phil kenny) : 2/25/2008 5:57:06 PM GMT
Subsequently, does your program have any problem with the check_drive routine, Phi? In particular, does it need anything like the 5000 millisecond delay that the rocketeers have noted? I am wondering about the 18 second (?!) delay from startup to taking data that Mark reported, where that is coming from.
Rocketeers, in the program, "Rocket_Robot_February_21.bs2", the movement sequence ended with a GOSUB main2, where main2 was the top of the program. That would start it over from the beginning, through all the initialization and delays. It might run, and one can't complain about success, but it does need work on the program structure. Taking a program back to the top with a GOSUB is not a good programming practice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
No extra delays were in the check_drive routine. It was the same as
in your Rocketeers_tta080223.bs2 file, except that I had a PAUSE 100
in there where you used PAUSE 1. I'll test it later today and make sure
that it still runs with PAUSE 1 in place of PAUSE 100.
I haven't timed the total delay in my program from power on until
data begins to get written to the SD card, but it is between 6 and 10
seconds.
On my board there are red and green LED indicators that get lit when
the SD file is closed and opened, respectively, so I can see what's really
happening after the Stamp is no longer connected to a PC.
My guess is that Mark is measuring the 18 seconds based on when
the robot tread starts to move. He doesn't really have anything else
to tell that he isn't stuck in a loop.
One reason I installed the file open/closed LEDs was to know when
it is safe to turn off power to the Stamp. Removing power when the
data file is open can leave the stored data corrupted.
phil
I revised my Check_Drive routine to exactly match yours, including
the PAUSE 1 statement and there was no problem with the program
hanging up on a cold start from the power off state.
I did, however, still need the PAUSE 250 statement in the loop that
checked for 'E' plus CR in the Vinculum initialization code. When that
was dropped to PAUSE 128, the code hung on a cold start. Only hitting
the RESET switch got it moving along and storing data to the SD card.
I have a DEBUG statement in my code to show when each write to the
data file takes place as well as the data actually being recorded.
Perhaps Mark could include something similar and get a better handle
on the true time it takes to begin logging data, instead of relying on
the robot tread movement as an indicator.
I have a better number for the time to start logging from a cold start.
It is 7 seconds with the PAUSE 512 and PAUSE 2048 statements that
take the Vinculum out of its RESET condition.
phil
··· Phil's right: the 18 seconds is measured from a 'cold' start-up until the robot starts moving. Here's the run-down:
Time = 0: Power on - The nylon pin is pulled from the jack mounted on the robot.
T +1 ---> 8 seconds: The Datalogger and flash drive synchronize. The Datalogger light goes red; the light·in the flash drive blinks rapidly. *There is a 5 second [noparse][[/noparse]PAUSE 5000] command in·this version of the·program (Rocket_Robot_February_21.bs2).
T +9 ---> 18 seconds: The sensor measures, and the Datalogger records, 10 samples.
T +19 ---> 23 seconds: The program cycles back through to the beginning and the Datalogger records data·(quicker this time because the Datalogger and flash drive don't have to re-initialize.) The ground movement subroutine kicks in; the robot moves; and the sequence repeats... again, and again, and again (which is GOOD!)
I've enjoyed reading and trying to figure out the flurry of posts between you and Phil the last day or so.·It's waaaaaaaaaaaaaaay over my head right now············· and·so I've held·off·on cutting-and-pasting·any more·debugs into the program for now (waiting·for the electronic dust to settle...!) I was with you (somewhat) up until 5 or 6 posts ago; then the program started doing just what Phil describe.
I hope you guys·don't feel like I'm 'slacking' in any way, but there's not much I can offer in the way of professional dialogue. I don't even want·to presume that I have a valid suggestion, and I certainly don't want to come across as a prima donna (prima marko?) So I sit aside, humbly, with hat in hand...
We ARE learning tons, guys·(on a relative scale at least), so don't give up on us now. This is too much fun, and it's a great education!
Thanks;Mama K says it's dinner time!·(veggie burgers for dinner, with ketchup, lettuce, and relish. I relish them.
>·
Mark and the Rocketeers
·· You wrote: "Removing power when the data file is open can leave the stored data corrupted." ~ SLI Team members take note! ~
This is good to know ("Now ya tell us...!")
Thanks for the heads-up,
Mark (the burgers are now gone)
Since no one has commented on this yet, I'll take a shot at it. However, Tracy
can give a much better answer since data logging is the business his company
specializes in.
Check out www.emesys.com/
It has a wealth of Stamp info there.
Most data logging applications use a battery backed up Real Time Clock (RTC).
These gadgets, once the time of day has been set, keep fairly accurate time,
even when power is shut off. One such device is:
www.sparkfun.com/commerce/product_info.php?products_id=99
www.sparkfun.com/datasheets/Components/DS1307.pdf
It requires a little soldering to get the signals and power connected, plus a small
battery. The price is pretty reasonable at $20 each.
They do need some code to function in a Stamp, but example programs are
readily available. What might not be available is enough free space in your
program with the existing BS2 Stamp. As Tracy mentioned, there are other
versions of the Stamp that can support larger programs. These would include
the BS2pe that he favors.
The other big factor weighing in against incorporating an RTC is the deadline
for launch. At some point before then you'll have to freeze the design of both
hardware and software and focus on final test.
Taking advantage of the extra code space in the other slots is a non trivial
programming activity, especially for folks just getting used to programming
the BS2 Stamp.
Maybe I've opened another can of worms by even mentioning the RTC, but if it
really is necessary to include a time stamp with each record stored in the
Memory Stick Datalogger, this is one approach. Capturing a stream of data
points without the time, greatly decreases the value of doing it.
phil
·· You make two good points (rather, point and counter point):
1) "At some point... you'll have to freeze the design of both hardware and software...:
Point well made, and well taken... and I think we're nearing the 'freeze'·point. We're slated to make an hour-long video teleconference with NASA on March 31st. A week before that (March 24th) we have to post our Flight Readiness Review report on our website (www.wearerocketry.org) so NASA engineers can peruse it before the students present to them. Posting the report to the website assumes that it's been written, which assumes that we are, 'flight ready.' I've asked Mollie, our Student Project Lead, to have the final draft of the FRR report in my hands a week before we post it so I can review it (to me by March 17th.) SHE has asked all the Subsysytem Team Leads (robot, rocket, recovery, etc.) to have their·sections written and to her by March 12th. That assumes that all the hardware and software work is done... You get (and made) the point: we're nearing the freeze point, and the freeze point is·a little more than·two weeks away.·
2) "Capturing a stream of data points without the time, greatly decreases the value of doing it."
Again, point well made and well taken (are you reading this, SLI Rocketeers...?) Why measure and record data if·we can't correlate it with altitude, which is our primary mission.· You feel our angst! Therein lies today's problem...· We have considered measuring flight time-- from liftoff to robot touchdown-- with a digital watch, then·comparing what we get·to the times/altitudes recorded by the on-board altimeters. Crude, but better than nothing.·We're open to (two week, low-tech, low cost) solutions!
The idea of using·an RTC seems enticing (somehow, in the same way that standing next to a cage full of tigers seems 'enticing'...!)·Unfortuntely I fear that we might well get side-tracked and never·finish·the·RTC 'job'·(and, we only have two weeks for ordering, shipping, engineering, programming... and other parts of the rocket to finish, and a report to write.)·I'd rather the students learn to do·one, or several things well rather than fast (as they're doing with the robot and the programming.) Yes, we do have a 'mission'. But·keep in mind that the project, the·rocket, and the robot are designed to be the literal vehicles for a bigger mission:·knowledge. At this juncture I'd say, "Mission accomplished!" (*but I still want to see the rocket fly, the robot landsoftly and safely, and get good data!)
Thanks for sharing
Mark
You commented that you and your team are as we speak using the program, "Rocket_Robot_February_21.bs2", but the most recent one I can find posted is "Rocket_Robot_IT_RUNS_February_21.bs2". Is that the same thing? We all need to be on the same page!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
· Same thing (same program, same page): We're currently running "Rocket_Robot_IT_RUNS_February_21.bs2". What's your read on the 'time' predicament? (see Phil's, and my, last posts.) Phil made a good point when he said, "At some point... you'll have to freeze the design of both hardware and software." I think includes integrating a Real-Time Clock
I've also·heard that "Many hands make light work." How true! These kids are learning a lot about the importance and value of teaming and team building. As a Boy Scout leader I emphasize to the patrol leaders (a patrol is a group of 6-8 Scouts) that they should find each Scout's strengths, then delegate accordingly. I also encourage them to know their own limitations and learn when to reach out for assistance from other patrol members or adult leaders. Some Scouts know how to tie knots very well, and some don't. Some are excellent·with first aid, while others·would hurt themselves putting on a band-aid. Likewise with computer programming. You guys are the experts.
Thanks,
Mark
··Attached is·the version of the program we're currently running: "Rocket_Robot_IT_RUNS_February 21, 2008.bs2. I previously·deleted·a few·of the 'commented out' comments, but it's largely unchanged since it was first posted.
Regards,
Mark
Sorry I haven't been on the forum, the internet at my house has not been working very well. The answer to your first question (Andrew, how long do the treads run for?)... The treads run for about 40 seconds, capture 3 data packets, run for 40 more seconds...
The answer to your second question (how long it takes to initialize from pulling the pin)... It takes about 15 seconds to initialize using my flash drive..
-Andrew
(I also have completed·a rough draft of·3 trials with the robot, and they are attached to this post)
·· Your trials, and your preliminary reports are a good start. You're maybe·halfway there and I would expand on them as suggested below.·I also like the idea of adding a clock on the robot. But is it fesaible? If not, what'sor best option? We do need to corrleate the data with flight time and altitude somehow...
Explore options·and solutions with Mr. Allen and Mr. Kenney; learn from them. And be sure to read the last three or four posts about adding an RTC (Real-Time Clock). We've already discussed some of the problems and limitations. Maybe our best solution is non-robotic...
Here are a few suggestions for your part of the FRR report:
1) Include the date, time, location (including city and state), and duration of all trials.
2) Write more comprehensively. Explain everything that happened: clearly, concisely, and thoroughly. "Paint" a very clear picture with words.
3) Consider including a (line) diagram of where the robot traveled during each trial as we discussed on Sunday. You could do this on the computer from·the hand-drawn sketches you made during the trials, to give it a more·professional appearance in the report.·This helps the reader visualize what happened even better.
4) Consider adding the 'raw' data (the Excel series of temperature and humidity readings) as 'Appendum A, B, anc C'·at the end of the FRR report.
5) Be sure to give everything a proper label and title (you can do this with the 'legend', etc. right on Excel)
6) What about including the total distance the roboto traveled, the total time of travel, and the lateral distance from the 'touchdown' spot (like we measured in the basement at my house?) Would calculating the robot's velocity (speed) be useful. Or would it just be extra, non-essential information. I would include the distances·and direction traveled·in your·diagrams.
7) Pictures, pictures, pictures! of the robot in action, and of the three different terrains. Include these in the FRR report.
8) Review our FRR report from last year (on the NASA SLI weblink,and on our website); review other team's FRR reports, too. Read NASA's FRR report requirements before you finalize your part(s) of the report.
9)·Finally, re-check everything for accuracy. You are a NASA contractor, and this is precision, NASA-quality work. Aristotle, I believe, said, "We are what we repeatedly do. Excellence then, is a habit, not an act."
Is there anything else that you can think of that we need to do on the robot? What about making a 'shell' that fits over it, to go on top of·the plastic static guard material? It would have to fit inside the·phenolic robot 'capsule' you have (the one with the string and the pin inside.)
Keep up the good work!·
Mr. Kibler
'Feasible' is spelled 'f-e-a-s-i-b-l-e', not ' fesaible'.
Oops,·
Mr. Kibler
How large a dome would you need to cover the top of the robot? I may have a surplus supplier in mind. They even have colors if that floats your boat
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Genius is one percent inspiration and ninety-nine percent perspiration."
Thomas Alva Edison
I'd like to continue the discussion of the ins and outs of the flash drive with Phil, but I think we will move that to another thread. It is tangential to the subject of the rocket mission.
On the subject of the real time clock. An RTC chip like the DS1302 would add a lot of value to your system and to your data. The RTC is an 8 pin chip that would plug into your white block protoboard on your BoeBot, and connect to power and a couple of the free Stamp signal lines. The chip also requires a 32kHz watch crystal, which would be soldered right to the two crystal pins on the chip, and a couple of capacitors. Here are considerations:
1) Is there room to fit it physically? Looking back at a photo posted earlier in this thread, I see that you have the white breadboard largely occupied by the flash drive interface and the Sensirion. Can you move those over to free up space for an 8-pin chip?
2) Do you have three unused signals pins from the Stamp? The DS1302 needs to use three i/o lines, plus Vss and Vdd. I think you do. From your program, I see the following:
That accounts for 6 pins, and two more are used (p14 and p15) directly for the servos. So that by my count leaves 8 pins unused. Is that right?
3) Is there room in the program to add more code? Well, the program you are using now occupies 99% of the available eeprom, and only 19 bytes are left unused. However, as has been pointed out several times here, you can reclaim a lot of that space by eliminating or tightening up the DEBUG statements. For example, the 5 DEBUG statements at the top of the program occupy 20% of the eeprom:
During the flight, who is going to read that? A simple DEBUG "top!" should be sufficient (and necessary) for debugging. There are many other things that can be done to reclaim space too, but I won't get into those here. Even the 20% reclaimed would be enough to add the code necessary for the RTC.
4) Do you have enough in your budget for the RTC? A DS1302 + 32768 Hz crystal cost $7.25 from Parallax.
5) Do you have time to incorporate it? There is plenty of help here if you are willing to do the work. I'd suggest you stick with and work within the constraints of the BS2 and not attempt to change over to a BS2pe.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
· The robot's 'shell' has to be nearly pancake flat because it has to fit inside a 4" diameter rocket/tube. That's 4" from side-to-side, leaving little wiggle room. The treads extend 1/2" each beyond the edge of the Parallax board, which is 3" wide (total width is right at 4".) The treads, spacers, and Parallax board are a little over 2" high. That leaves maybe an inch or so for the 'shell'. I was visualizing something like·a calculator's·hard case, etc... nothing fancy-schmancy, just enough of a shell to add one more layer of protection. A colorful protective shell·sounds nice! (assuming the shell fits.) The robot is a little longer than a Parallax board, and I think Andrew posted photos a few pages back. Let·us know what you have in mind!
Mark
· ·You ask some valid questions and make some good points:
Do you have enough in your budget for the RTC? - A DS1302 + 32768 Hz crystal cost $7.25 from Parallax.
The answer there is, "yes" (just barely)
Is there room to fit it physically?
Ibid: The answer there is, "yes" (just barely)
Do you have time to incorporate it? There is plenty of help here if you are willing to do the work.
That's more difficult to answer, and the answer is "yes" and "no". If you recall·the timeline I posted earlier today, we only have two weeks or so left before the Flight Readiness Review (FRR) to get EVERYTHING done. That includes a lot: writing and posting the Flight Readiness Review (FRR); making·and posting·an FRR PowerPoint presentation; finishing the second Parallax-PASPort module (the ASP) that mounts inside the nose cone; hardwiring everything and bench testing it; ground testing everything; and regular classes. While my heart says, "Go for it" my experience says,"Uhhhhhh... think before you leap."
One·point I·don't believe·that I've made clear is that none of these student rocketeers·are in the same school builidng·I'm in!·That complicates things, especially the hands-on work. Three attend classes at the local high school, one is in prep school 2 hours away, one is home schooled,·and·one lives and goes to school nearly an hour away. Four of the six were former students of mine in middle school; two, including my son,·were on a robotics team I·mentored a few years back.
We meet once a week on Sunday afternoons to do all the hands-on work, then scatter like seeds to the wind after practice. We try as hard as we can to stay in touch by e-mail and the forum during the week, but sometimes that's just not enough time. Reality is what reality is, and we try to do as much as we can.
With that said, and in good faith, I'll go ahead and order·a DS1302 + 32768 Hz crystal from Parallax.··
I'm going off-line to place an order to Parallax. With any luck it will get here before Saturday.What's another 20 bucks at this point anyway?!
More later,
Mark
·· I just placed·the order for a·Parallax·DS1302·and 32768 Hz crystal that Tracy suggested. With three day shipping, it should be here·on Friday...~ !Yippee!··
Andrew and Tim, please start reading the 'tech specs' (technical specifications) for the Parallax DS1302 RTC (real time clock) so that you're familiar with it before Sunday's practice. Be sure to print out the instructions and schematic drawings·for how to wire it into the robot's PCB (printed circuit board.) Andrew, you'll start there on Sunday. Consider asking questions ahead of time so we can dive right in.
Mr. (Mark) Kibler
In what post did I use the word 'feasible'?
Andrew