|
   |
 |
|
U P D A T E # 11 PART 1: WebChat
with other Jupiter heads
Online from Jupiter now has a chat room. Here you may type brief thoughts and then send them. All the while other people are doing the same thing at the same time. The hardest part is timing your visit to WebChat so that you'll find someone else is also there. One suggestion is to leave a message with a time when you plan to check back. And then come back at that time WebChat can be found in the Teacher's Lounge with this URL: http://quest.arc.nasa.gov/galileo/webchat/chat.html
During past projects, we have received comments that some of the updates are too long or that some vocabulary/concepts are too difficult for the average middle schooler. So for this project, in addition to the regular Field Journals, we will be offering an easier- to-read version geared towards an average 5th/6th grader's interests and vocabulary. These messages are being distilled from the regular messages by some committed volunteers; we all owe them our thanks. To receive these Junior Journals, send an email message to listmanager@quest.arc.nasa.gov In the message body, write only these words: subscribe junior-jup The first Junior Journals will be sent out early next week.
[Editor's note: This may sound like a foreign language to you and I. We likely don't understand it. But it is the way the Galileo team often speaks.] Message sent Saturday, November 18 at 01:49 AM local (Pacific) in the midst of a Galileo test - Gregory R. LaBorde reporting: Online from Jupiter is really helping to pass the time here. We're just passing Europa, and the Galileo CDS-A is 5hrs and 20min away down". Then we'll "cock" the A-string Probe Editor using a real-time command (since the sequence will die on CDS-A) and see that we can still complete Probe Relay with the string effectual down. The next day, Greg reported: The CDS survived both bus resets to complete the Probe Relay and JOI, FYI. Stephen Licata October 26, 1995 The Galileo Flight Team spends many months planning complicated science and engineering activities, but sometimes the most nervous time is spent waiting for the results to appear on the computer screens at their desks. As part of my job, every once in a while I call a meeting of the Galileo Data Flow Working Group to make sure this process runs smoothly at critical points in the mission. I'd like to share with you one of our recent assignments - planning the release the Probe from the main spacecraft so that it could begin its descent into Jupiter's atmosphere. First, let's look at how the spacecraft data gets to Earth. On Galileo, the Command and Data Subsystem gathers information on all parts of the spacecraft (cameras, science instruments, even the heaters and gyroscopes) and creates a "status report". This report is sent to earth through the low-gain antenna at a radio frequency around 2300 on your FM dial (Don't bother trying! The signal is put into a secret code to protect it from static and interference in space and the Earth's atmosphere). On the ground, these radio signals are captured at the Deep Space Network by huge tracking antennas the size of a football field and converted into the computer language of 1's and 0's. The tracking station computers tell us at what time the signal was received and then send it by a special network of wires and radio relay antennas to JPL. Here at JPL the Data Systems Operations Team converts the data into a structure that can be understood by JPL's computers and passes the data on to a set of computers and computer programs called the Multi-mission Ground Data System (MGDS). The MGDS separates the data into categories of "spacecraft science data", "spacecraft engineering data", and information about the tracking station (for example, how strong the radio signal was when it was received at Earth). Immediately some of these data go to the Mission Support Area where the mission controller, a person called the "Ace", looks at the data and promptly calls the tracking station if there is a problem with the data stream. At the same time all the data related to the spacecraft goes to another part of the MGDS called the Telemetry Delivery Subsystem which is like a library where people with special permission (like the scientists) can go to grab the data that they want. If the data they want are parts of a camera picture, these data first have to go to yet another area called the multi-mission Image Processing System before they can be looked at by the scientists and others. Currently the time required for the data to go from the Deep Space network to a scientist's computer screen varies from 10 minutes to an hour (for the pictures). Early next year, we will be changing the computer software on the Galileo spacecraft such that this time delay may stretch to two hours but we will be able to get many more pictures each day from the spacecraft, so scientists are willing to be a little more patient! In planning the release of the Galileo Probe last summer, we had a few special problems. First of all, since the Probe, once released, cannot talk to the Galileo Orbiter until it begins to enter Jupiter's atmosphere, we wanted to be very sure that everything was working fine before we let it go. Therefore, the Probe Engineering Team asked that we first turn on the Probe using an electrical cable from the Orbiter to make sure everything was working correctly. Then we had to switch the Probe to its own internal power before cutting this power cable (just like a baby being born gets separated from its mother!). A second challenge was that the computer equipment used by the Probe Engineering Team is not the same as used by the rest of JPL. Therefore, we needed to record the Probe information on special data tapes. For each of these two key events - turning on the Probe and switching it to its own internal power, we commanded the Galileo spacecraft to issue two status reports each time. This allowed us to be VERY sure that there were no problems with the spacecraft reports. As it turned out, this was a lengthy process, with data coming in from the spacecraft as late as 10:30 p.m. and these tapes being delivered sometimes at 2:30 am. My job in all this was to identify where the data was going when it arrived at the Deep Space Network and to negotiate between the Probe Engineering Team and the Data Management team (the data tape folks) this rather unusual set of delivery times. In the end, everything ran very smoothly and the Probe Release on Wednesday July 12 went off perfectly! We will be going through a similar process in December when the Probe enters the atmosphere and starts sending back "real data". Even now I am updating that same tape delivery schedule. Keep your fingers crossed! Marcia Segura August 25, 1995 At 5:30 am, my day begins as I'm wakened by the radio blaring "golden oldies". I prefer this option to the annoying buzzer! After the usual preparations for the day ahead, I leave for JPL. I've got one VERY IMPORTANT stop to make this morning before I go to the office. You see, the NIMS (Near Infrared Mapping Spectrometer) is in the TestBed (a special place that houses a "virtual" Galileo and engineering models of the science instruments) today and it is Galileo tradition that the science team du jour provide breakfast for the TestBed personnel. Traditions must be maintained so Donut shop here I come. Mission accomplished!!! I found 2 dozen of the most sugar-laden and artery-hardening donuts known to man or woman. This NIMS testbed day is scheduled to start at 8:00 am. We will be testing the new NIMS software and the new Galileo spacecraft software. We want to make sure that all the software works well together before we send it to the instrument and the spacecraft. About 7:45 a.m., I arrive at the Testbed. Gerry Snyder, the test conductor, and I spend a few minutes discussing the day's test, procedure, and schedule. The "virtual" spacecraft, associated computers, and software will be up and operational by 9:30. The NIMS instrument will be turned on shortly thereafter. All the science instrument models are kept in a room separate from the TestBed crew and the spacecraft. This is necessary for a number of reasons, but most importantly for instrument safety. The project doesn't want *anything* to happen to the engineering models because they would be extremely expensive to replace--that is, IF replacement was possible. The instrument models are mounted on special tables and are protected by covers built just for them. The instruments are sensitive to their environment so we have to be very careful when we work in the room with them. We wear special lab coats and have to walk across "fly paper" when we enter the room; both the coats and the fly paper help to protect the instruments from dust and dirt. We also wear grounding straps when working close to the instrument because we do not want electrical charges to cause damage to the instrument's electronics. At 9:00 a.m., Al Stevenson (he's our instrument engineer) and I put grounding straps on and removed the cover from NIMS. We always take great care in lifting the cover but I still feel much better when this part of the job is done. Next, I configure the computer that we'll use to monitor the instrument during the test. The final set-up step for NIMS is the communications check; because the test activities happen in two places we use a voice net. So, on goes the GLAMOROUS headset! You know, Alpha, Bravo, Foxtrot....... Tango, X-ray. At 10 a.m., NIMS is ready to proceed with the day's testing activities. A status check with the test conductor reveals that the "ground system" (that is, what's down here on Earth) part of the software is not working correctly. There was a new version delivered and OOPS we were the fortunate ones to find the BUGS! The planned work-around is to use the older version. Estimated time of test start is now 12:00 noon. A decision was made to slip the start time until 1:00 to give the crew time for lunch... It's now obvious we won't be home for dinner. We returned at 12:45 only to discover that the 1:00 test would be slipped until 2 p.m.; the software load was in progress but not complete..... We turned NIMS on a little after 2 and started the test at 2:30 p.m. Everyone breathed a sigh of relief. Part of the test requires loading the new NIMS software into the instrument memory. To check that the load occurred correctly, we perform a test on the software known as a "checksum"--we then compare the results of the test with the predicted result (rather like checking a test paper against the answer key). If the two results are the same, we can feel confident that the software loaded correctly. You'll never guess what happened next?!! The results WERE DIFFERENT!!! What now? We had two options - continue and see what happens or abort the test. We decided to continue - the instrument didn't work. A memory readout (which will help us figure out what's wrong) was done quickly before everything crashed! It's now 4 p.m.! We spent the next 60 minutes poring over the memory. One of the 2646 characters was incorrect. A spacecraft command was created to fix this and we restarted at 5:30 p.m. Another "checksum" was done and this time everything matched up. The test executed as expected, pausing activity conveniently at 8 p.m. for the crew to eat the pizza under the stars. (Pizza Hut delivers!) The NIMS testbed activity concluded at 11:45 p.m. but the surprises of the day weren't over yet. As Al and I were leaving the building, 2 raccoons sat just outside the door waiting for handouts. The testbed crew brings an assortment of nuts and seeds for them. They also are quite partial to leftovers of any kind!!! Hand feeding them was a fun experience but that's not all! We also saw 5 deer cross the street in front of us!!! This day has been different and challenging to say the least. It's Friday or almost Saturday.... This week has been incredibly busy. It's been filled with last minute errands and final arrangements for the fateful trip to Boston that I've been anticipating and dreading. Adrian, my oldest son, will be attending Emerson College there and I'm helping him get settled in. I am truly excited for him but I will miss him terribly. Parents spend 18 years hanging on and then in 18 seconds you have to "let go". And they say kids have it rough! Oh well, there'll be just enough time for a couple hours sleep and suitcase packing for the mid-day flight. Day's End - Marcia Segura "Online from Jupiter" Lou D'Amario November 13, 1995 Jupiter Orbit Insertion (JOI) Tweak I discussed the JOI tweak (the late update to the size of the JOI maneuver) in some detail in my last journal entry. The next day, the Navigation Team was told that the Project was seriously considering eliminating the JOI tweak (see my last journal for an explanation about tweaks). This was disappointing, because the JOI tweak is an important part of the overall navigation strategy for the Jupiter encounter. The problem was that the Flight Teams were very busy changing the spacecraft sequences because of the tape recorder problems. There didn't appear to be time for the Orbiter Engineering Team and the Sequence Team to run through a test and training exercise for their parts of the JOI tweak development before arriving at Jupiter. By Monday November 6, I was able (with the assistance of Mike Wilson and Chris Potts, who also work on the Navigation Team as maneuver analysts) to show what would happen if we eliminated the JOI tweak. The first JOI- correction maneuver at JOI plus one day (called OTM-1, the first Orbital Trim Maneuver) could get much larger, calling for more propellant. That was not good, but there was a bigger problem. If for some reason we were unable to perform OTM-1, the next maneuver (OTM-2) could get so large (in some situations) that there might not be enough propellant left to finish the full orbital tour! This became a real dilemma. On Tuesday, I suggested a possible solution to Ralph Reichert, the Engineering Office Manager: scratch the JOI tweak test and training exercise, and keep the JOI tweak in the plan, but only on a so-called "best efforts" basis. In other words, the Flight Team would try to do the work required for the JOI tweak in the time we have. Then, if we did manage to get ready for the tweak (and the JOI tweak was judged to be desirable), the tweak commands would be sent to the spacecraft. On the other hand, if the work wasn't finished in time, no commands would be sent, and we would accept the consequences. What made this strategy feasible was that the exact same work needed for the JOI tweak had, in fact, already been done once a few months ago after the Orbiter Deflection Maneuver; it just hadn't been done on the short timeline of the JOI tweak. As of today, the JOI tweak is still in the plan (and we have our fingers crossed). Arrival Day Telecom Meeting On November 6, I attended the Arrival Day Telecom Strategy Meeting. This meeting was about how to configure the spacecraft and the DSN (Deep Space Network) ground antennas to make it as likely as possible that we will be receiving telemetry (data sent from Galileo) on December 7, the day that Galileo arrives at Jupiter. There were no major effects on navigation plans (we lost one tracking pass before the Io flyby, and the backup "uplink window" (the time period where we send commands up to the spacecraft) for the JOI tweak was moved later). Trajectory Change Maneuver 27 (TCM-27) Starting on November 8, the Navigation Team had one regular working day (8 hours) to finish working out exactly how great a change in velocity would be needed for the trajectory change maneuver (TCM-27). This maneuver improves our aim for when Galileo flies by Io. This work involved the following steps: First, the Orbit Determination (OD) Group "generates a solution" (more on this later) for the spacecraft trajectory (the spacecraft's path) and the predicted Io flyby conditions using the most recent tracking data available. Then the Trajectory Analysis (TRAJ) Group checks the OD solution by mathematically "moving" the spacecraft all the way to Io closest approach to see if the Io flyby will match the predictions. Since we never get an exact match, the Maneuver Analysis (MNVR) Group then calculates how we have to maneuver the spacecraft so that it is perfectly on target (specifically, they calculate a velocity vector that will correct the miss in the Io flyby conditions). Once again, the TRAJ Group checks the spacecraft's trajectory ---but this time with the maneuver added in. If everything checks out, the Group sends the maneuver information to the Orbiter Engineering Team (OET); it' s the OET that will translate the Navigation team's request into actual commands for the spacecraft's thrusters. Finally, the results of all this work were presented to the Project managers. Here's a summary of the results. The desired Io closest approach altitude is 1000 km, and the desired closest approach time is at 17:45:44 UTC on December 7, 1995 (UTC refers to the 24-hour clock time at Greenwich, or 5:45:44 PM at Greenwich. At JPL, that will be 9:45:44 on the morning of December 7). Without TCM-27, Galileo would miss its aimpoint at Io by a predicted 84 kilometers in altitude (a large error), arriving 5 seconds early. To correct these errors, the spacecraft velocity would have to be changed by 0.16 meters/second (a small maneuver). Then, at the conclusion of the presentation, the Navigation Team recommended that TCM-27 be canceled! Why did we do that? There is some additional information about the maneuver design process that I haven't mentioned yet. When the OD Group "solves" for the trajectory, what they are really doing is finding the trajectory that best "fits" the radio tracking data. In other words, orbit determination is basically finding the trajectory that differs as little as possible from the observed tracking data. When the OD Group determines the best trajectory fit, they are also able to say how "good" the fit is - i. e., how small the differences from the observed tracking data are. For TCM-27, the errors in the Io flyby were small relative to these differences -- we didn't know the miss at Io accurately enough to say that correcting the errors at TCM-27 would actually improve the trajectory. In recommending to cancel TCM-27, we were saying that we needed to wait until the spacecraft got closer to Io and Jupiter so that the "goodness" of the trajectory solution would improve. The Project accepted the Navigation Team recommendation, and TCM-27 was canceled. The next maneuver, TCM-28, is scheduled for November 27 (Io minus 10 days). The design of TCM-28 starts on November 18. We will have 10 more days of tracking data to reduce the uncertainties of the trajectory (i. e., improve the "goodness" of the fit). I expect that the Navigation Team will not recommend canceling TCM-28. Non-Work Stuff So far, the increased level of activities at work have not disrupted my exercise schedule. I am still riding my bike or walking every morning for 30- 35 minutes; on Saturday and Sunday I go for a longer bike ride (about an hour). So far, the Navigation Team has not had to work nights or weekends, but that will change for the upcoming maneuvers and the JOI tweak. We will be working this coming weekend and the weekend after Thanksgiving. And there are some all-niters coming. At home, my wife Maria and I are planning to have some work done on our kitchen - new floors, countertops, appliances, lighting etc. She will have to assume responsibility for negotiating with the contractors for this work until after Jupiter arrival - I'm just too busy right now. I plan to take some vacation time at Christmas. My mother is coming Barbara, will also be at our house for Christmas. If this is your first message from the updates-jup list, welcome! To catch up on back issues, please visit the following Internet URL: http://quest.arc.nasa.gov/galileo/journals/index.html |
||
|
|
|
