Index Home About Blog
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: sci.space.science
Subject: Re: If there is life on Jupiter ......
Date: Sun, 10 Dec 1995 21:55:33 GMT
Organization: U of Toronto Zoology
Lines: 21

In article <4adduj$jso@lace.colorado.edu> fcrary@rintintin.Colorado.EDU (Frank Crary) writes:
>...if there's
>still enough fuel in the tanks at the end of
>two years, there might be money for an "extended
>mission." Given the current political climate
>and concerns for reducing the federal budget,
>there may be little chance for an extended mission,
>even if there is fuel for it. 

Actually, I'd say the way to bet is that towards the end of the nominal
mission, the question will be:  "Can you get some important result from a
*short* extended mission which the spacecraft is unlikely to survive?"  If
the answer is "yes", that particular extended mission will be funded.  The
political embarrassment of turning off a functioning spacecraft will be
avoided by sending it on a kamikaze mission.  (Had the HGA deployed, a
Ranger-style kamikaze dive into Io would be a likely ending.  Very low
data rate complicates such missions, and I'm not sure what would be
suggested now.)
-- 
Look, look, see Windows 95.  Buy, lemmings, buy!   |       Henry Spencer
Pay no attention to that cliff ahead...            |   henry@zoo.toronto.edu

From: Henry Spencer <henry@zoo.toronto.edu>
Newsgroups: sci.space.tech
Subject: Re: Galileo Antenna Question (was Re: Cassani Question)
Date: Fri, 16 Feb 1996 14:07:37 GMT

In article <4fu01i$m0f@cdn_news.telecom.com.au> Julian Bordas <JBordas@vcagmkt1.telecom.com.au> writes:
>Why was the HGA not unfurled as soon as galileo was on the way?

Originally, it was supposed to be unfurled *before* Galileo was on its
way.  The original launch plan had the HGA unfurled before release from
the shuttle, so that any problems could be dealt with by humans.

Unfortunately, this all got messed up when, in the aftermath of Challenger,
the safety paranoids decided that it was unacceptable to put a Centaur in
the shuttle cargo bay.  That meant that Galileo had to resort to batting
around the inner solar system for a while doing gravity assists, and *that*
meant that the HGA had to be kept furled for a while, because it could 
overheat if exposed to the Sun at less than Earth's distance.

To cap it all off, the antenna deployment motor was originally reversible.
It had to be, because with antenna deployment before shuttle release, the
deployment had to be reversible in case release was cancelled at the last
minute.  Unfortunately, the relay used for the reversing was swiped for
some of the inner-solar-system-tour modifications... after all, there was
no longer any requirement for reversing the motor...
-- 
Space will not be opened by always                 |       Henry Spencer
leaving it to another generation.   --Bill Gaubatz |   henry@zoo.toronto.edu

Newsgroups: sci.space.history,sci.space.policy
From: Henry Spencer <henry@zoo.toronto.edu>
Subject: testing (was Re: Smaller, Faster, cheaper)
Date: Sun, 26 Oct 1997 21:47:13 GMT

In article <62tjku$ua17@beaker.nit.gwu.edu>,
Dwayne Allen Day <wayneday@gwis2.circ.gwu.edu> wrote:
>: ...Flying a bunch of
>: small cheap probes means that, when you do have a failure, the problem
>: can be diagnosed and a design fix done on the next one to be sent out...
>
>I doubt that this is truly a problem--the space environment can be
>simulated fairly well on the ground...

I'd say that's a little naive:  specific aspects of the space environment
can be simulated fairly well, but not the whole thing.  (For example, most
big space-simulation chambers can't pull a high enough vacuum to let some
of the more sensitive electric-propulsion devices run realistically.)
Which means you have to guess which are the most crucial aspects, and you
don't always guess right.

>The problem is cost, which is the
>enemy of fastercheaperbetter.  So you don't simulate and you run the risk
>of losing it, but at least it's flying.

Actually, ground simulation and engineering analysis share the same
weaknesses:  not only are they costly, but they *can't* capture the total
environment, and most failures are due to out-of-the-blue surprises rather
than anticipated effects.  Old-style projects like Galileo got the best of
everything in analysis and simulation, and still have had one problem
after another -- I count *five* separate major problems discovered on
Galileo after the hardware was built and tested, and there may be more
that I don't know about.  There is no substitute -- none, at any price --
for in-space testing.  The worst problem with trying to achieve high
reliability by elaborate analysis and detailed simulation is not that
it's expensive, but that it DOESN'T WORK.

(Oh, the five problems?  The high-gain antenna didn't deploy.  The tape in
the tape recorder tends to stick.  The thrusters can explode if fired in
long steady burns, which is why Galileo always fires them in pulses, and
need to be burped regularly to avoid slow propellant decomposition --
TVSat 2 fortunately used the same thrusters, was launched before Galileo,
and had a solar array fail to deploy, so its thrusters were fired long and
hard during attempts to shake the array loose.  The star scanner used for
attitude sensing has design flaws which make it impossible to point
Galileo in certain directions, because it wouldn't see enough bright stars
to get good attitude data.  And the two G-switches in the atmosphere probe
were cross-wired, so the probe switched on late and missed some early data
of considerable interest.)

(All of these things could easily have been found during testing... had
anybody known exactly what to test for.  In fact, people thought they
*had* tested for some of them.  For example, the probe G-switches were
tested in a centrifuge, but apparently the test setup was cross-wired
too... a type of problem that has affected other subsystems in at least
two other spacecraft since.)

>: [1] Here's a silly question: why aren't mission critical subsystems
>:     like folding antennas wrung out in Earth orbit on a test article...
>
>I think that you're probably asking this in reference to Galileo.  In that
>case it would have made no difference if a test article was "wrung out"
>ahead of time--the problem was that the actual hardware had sat on the
>ground for too long...

A note of caution:  we *think* that was the problem.  It's no more than
the best guess; there is no specific evidence confirming it.

I would also note, as I've mentioned before, that the original mission
plan -- with Galileo using a Centaur upper stage and no gravity assists --
had the antenna deployed before release from the shuttle.
--
If NT is the answer, you didn't                 |     Henry Spencer
understand the question.  -- Peter Blake        | henry@zoo.toronto.edu


From: henry@spsystems.net (Henry Spencer)
Newsgroups: sci.space.science
Subject: Re: Cassini fly by of Jupiter
Date: Wed, 7 Jul 1999 14:43:33 GMT

In article <37826F1D.6DDA@pdnt.com>, Brian Davis  <bdavis@pdnt.com> wrote:
>   And while were at it, what are the chances that Galileo will still be
>opperational around the time of the Cassini/Jupiter encounter?

Very uncertain.  The current extended mission's climax -- two Io flybys --
was carefully crafted as a way to get good science with a flight plan that
seemed likely to kill Galileo.

These days, there is pressure to bring planetary-science missions to
definitive ends, rather than having them go on and on and on, eating up
operations money until a random fault finally kills the thing at some
unpredictable time.  NASA doesn't like admitting this, but the planners
are increasingly being encouraged to find ways to end missions once and
for all in scientifically-useful ways.  Sometimes a mission will get
extended funding on the unspoken condition of finding a way to terminate
the mission before that money runs out -- not by blatantly switching the
spacecraft off, since that's bad PR, but by doing something scientifically
respectable which *just happens* to require killing the spacecraft.  (Note
Lunar Prospector's impending impact experiment, for example.)

That's a little tricky for Galileo, since its return data rate is so low
that any dramatic encounter has to be followed by an extended period of
trickling data back.  (Before the antenna problem, one proposal for a
Galileo "extended" mission was a Ranger-style suicide dive into Io!  Lots
of high-resolution data, but it needed a high radio data rate...)  But
the radiation dose it picks up during the first Io encounter will be
pretty hefty, and if you wanted to have a high probability of keeping
the spacecraft healthy, you probably wouldn't do the second one.  They're
going to do it anyway.  Don't bet lots of money on Galileo still being in
operational condition afterwards.

If Galileo is still limping along after the second Io encounter's data is
all back, there is going to be some awkwardness over funding for any
further mission extension.  In Galileo's case, there is an extra problem:
getting even that low radio data rate requires major commitments of DSN's
limited resources, which is increasingly difficult to justify.  It might
just be possible to get funding and communication resources for a quiet,
low-activity extended mission with very limited data rate (no pictures!).
--
The good old days                   |  Henry Spencer   henry@spsystems.net
weren't.                            |      (aka henry@zoo.toronto.edu)


Newsgroups: sci.space.history
From: henry@spsystems.net (Henry Spencer)
Subject: Re: Space mysteries
Date: Sun, 2 Jan 2000 19:06:45 GMT

In article <386f213c.4075108@news.uni-stuttgart.de>,
Jens Lerch <jlerch@geocities.com> wrote:
>>And Galileo would have got to Jupiter a lot sooner,
>
>or not at all, because I have heard (others will correct me if I'm
>wrong...) that a fatal flaw in the propulsion system of Galileo hadn't
>been discovered, if it had launched in 1986 as originally planned.

Correct.  During the shuttle downtime, TVSat 2, which used the same
thruster design, had trouble deploying one solar array after launch.  The
problem almost certainly was that some ground-transport retaining bolts
had not been removed before launch, but various things were tried on the
chance that the problem was more minor.  Some of this involved prolonged
thruster firings, and during those, some of the thrusters exploded.

This is why Galileo's thrusters are always fired in pulses, never
continuously, despite some performance penalty in the larger maneuvers.
Also, they are "burped" regularly to clear stale propellants out of the
plumbing.  Some small hardware changes were made before launch, but at
that late date, it wasn't feasible to redesign drastically enough to
eliminate the problems completely.

Galileo actually has had a *lot* of hardware problems, some of which have
not been publicized.  Only a lot of sweat, and quite a bit of sheer luck,
have kept it working.  A close look at its history really raises doubts
about the idea that faster/cheaper/better has caused a decline in quality.
--
The space program reminds me        |  Henry Spencer   henry@spsystems.net
of a government agency.  -Jim Baen  |      (aka henry@zoo.toronto.edu)


Newsgroups: sci.space.history
From: henry@spsystems.net (Henry Spencer)
Subject: Re: Galileo probe
Date: Thu, 13 Jan 2000 06:59:31 GMT

In article <387e25a8.263164621@news.erols.com>,
Chris Manteuffel <foxbat27@aol.com> wrote:
>A while ago, (when I was still lurking, before I started to post my
>questions) someone (Henry?) mentioned that there were multiple
>glitches with Galileo, (not just the antenna problem)...
>1) What other problems happened?

Let's see.

Everybody knows about the antenna problem.

The tape recorder has acted up several times, because it was left idle for
far too long early in the mission -- you're supposed to exercise them
regularly.  It's been nursed along very carefully indeed, because given
the low data rates from the antenna failure, the tape recorder is very
important and there's only one of it.

The star scanner which is the ultimate reference for the attitude-control
system has a major design flaw in its signal processing.  There are
directions Galileo cannot point in, because there is no suitable star set
that the scanner can track when pointing that way.  The underlying problem
is that nobody noticed that all the pre-launch testing of the design was
being done with data for only two or three pointing directions.

Frank has already mentioned the voltage-sensing problem that caused some
spurious transitions to safe mode.

The thrusters have a high risk of exploding if fired long and hard.  This
was discovered purely by chance, when Galileo was delayed by Challenger
and a commercial comsat using the same thrusters had a solar-panel jam and
did a lot of thruster firings trying to shake it loose.  Some minor
hardware changes were done, but mostly it's procedural -- the thrusters
have to be fired only in pulses, and burped regularly when not in use --
at a significant fuel cost.

The check valves in the main propulsion system gave some trouble, not
reseating properly after use, threatening to permit some mixing of
propellants in the plumbing.  I forget the details, but it was a real
worry in the short period between the first use of the system and the
time when most of the fuel had been used up (giving lots of empty space
in the tanks to absorb any unwanted pressure surges).

The G switches in the atmosphere probe were cross-wired, which is why the
probe came on and started recording data slightly later than intended,
losing some data on the upper atmosphere.  They were tested in a
centrifuge, too -- the test harness must have been cross-wired to match.
(Such problems are not rare; great care is needed to avoid them.)

I think that's the lot...  Some of these you wouldn't find out about
unless you read some pretty obscure sources.  For some reason they don't
issue press releases about such things. :-)

>2) Were they caused by the same problem that they think caused the
>antenna problems (the ride back from the Cape)?

No.  Different causes for each problem.  Even the cause of the antenna
problem is still a bit speculative:  nobody's *sure* that the ground
transportation caused lubrication problems, that's just the best guess.

>3) Were they reflective of the problems that happened to other battle
>cruiser type probes (ie Mars Observer)?

Here and there.  The check-valve problem is quite similar to the
number-one suspected cause of the MO loss.

>4) Has Casini been checked for similar problems?

Undoubtedly.  People are always very careful about checking for old
problems; it's the new ones that bite you.
--
The space program reminds me        |  Henry Spencer   henry@spsystems.net
of a government agency.  -Jim Baen  |      (aka henry@zoo.toronto.edu)


Newsgroups: sci.space.policy
From: henry@spsystems.net (Henry Spencer)
Subject: Re: spacecraft reliability (was: Re: Why not X-33?)
Date: Wed, 13 Sep 2000 14:46:58 GMT

In article <39A1EC3C.9DD28C11@nospamplease.erols.com>,
rk  <stellare@nospamplease.erols.com> wrote:
>> >>Galileo ...
>> ...but the tape-recorder problems were a case of people simply
>> not paying attention to known duty-cycle issues, and the star-scanner
>> problems came about because of grossly, inexcusably inadequate testing,
>> and both of these were ultimately management failures.
>
>Do you have references to the tape recorder and star scanner issues?  I'm
>interested in reading up on these.

(Okay, so I'm slow about responding sometimes...)

No specific references on the tape recorder beyond the AW&ST coverage, I'm
afraid; my further info on that came via informal channels.

On the star scanner, see the paper in the proceedings of the Third
International Symposium on Spacecraft Flight Dynamics, ESA SP-326 (1991),
which mentions -- among other things -- that prelaunch simulation and
testing of the system used only two sample attitudes!  In flight, circa
25% of all attitudes require at least lowering the quality-of-fit
threshold, there are some attitudes where there simply is no set of stars
which will give a reliable attitude fix, and even for attitudes where it
does work, setting it up is difficult and manpower-intensive.  The
underlying design problem is that it does too much filtering too early,
giving somewhat-cryptic data which is difficult to relate to attitude, and
this wasn't caught because of the inadequate testing.
--
Microsoft shouldn't be broken up.       |  Henry Spencer   henry@spsystems.net
It should be shut down.  -- Phil Agre   |      (aka henry@zoo.toronto.edu)

Index Home About Blog