MGS in Trouble, Formerly: MGS in safe mode |
MGS in Trouble, Formerly: MGS in safe mode |
Guest_Analyst_* |
Nov 8 2006, 11:50 AM
Post
#201
|
Guests |
Did nobody notice this:
Ground Team Stays Busy on 10th Anniversary of NASA Mars Launch Ten year after launch, there is some trouble with a solar array motor and a comm problem probably resulting from this and entering safe mode. Nothing dramatic yet, but something to follow closely. There are other things than MRO and MER Analyst |
|
|
Apr 16 2007, 03:37 PM
Post
#202
|
|
Senior Member Group: Members Posts: 3419 Joined: 9-February 04 From: Minneapolis, MN, USA Member No.: 15 |
That was an excellent summary, Don -- it demonstrates what I've been saying all along, that the limitations on most every human endeavor have more to do with financial and schedule pressures than they do with the limits of our technology or imagination.
Now, as we all know, there are a lot of ways to automate the processes you discuss. Heck, back in Gemini days, more than 40 years ago, command loads to the Agena target vehicles were sent up pretty much exactly as you describe, here. But even back then, they had an automatic comparator that would check the command load as sent against the command load as received by the Agena. Only when that comparator failed did they end up digging through printouts of the command loads to verify that the load was properly received. Now, that's not exactly the same as comparing an actual command load to a desired command load, but its similar in process. And thus, the technology to error-check a lot of this stuff has been around for a long time. As you have so effectively pointed out, the ground support stuff is usually designed (or used off-the-shelf) to do its job, bare-bones, no extras. Error trapping is almost non-existent. And lest anyone think that this is just an issue with ESA's efforts, recall that an average command load to the MERs requires most of an individual's workday to prepare -- seven or eight hours. We all know it's *possible* to create error-trapping front-end software for such things that would allow a rover driver to tell the front-end interface: "We want to drive 20 meters in this specific direction, take the following image series, and then prepare for an overnight Odyssey pass." It's very possible to set it up so that creating and radiating the appropriate command series would take the rover driver 10 or 15 minutes, and the front-end would ensure that all commands sent to the spacecraft would be safe and properly executable. Why isn't it done like that? Probably because it would have cost too much in time and money to develop such a front-end system in the first place... -the other Doug -------------------- “The trouble ain't that there is too many fools, but that the lightning ain't distributed right.” -Mark Twain
|
|
|
Lo-Fi Version | Time is now: 18th May 2024 - 09:46 PM |
RULES AND GUIDELINES Please read the Forum Rules and Guidelines before posting. IMAGE COPYRIGHT |
OPINIONS AND MODERATION Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators. |
SUPPORT THE FORUM Unmannedspaceflight.com is funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member. |