Space X January 2006 Update
Space Cadet
I'm forwarding this update:
I wish him luck!
January 2006 Update
New Launch Time
The new launch time is February 8 at 4:30 p.m. California time with
Feb. 9 as a backup day. We will actually be ready to launch earlier,
but are planning to spend extra time reviewing and double-checking all
vehicle systems.
Following the problem on Dec. 19, we flew a whole new first stage to
Hawaii via C-5 just in time to catch the barge from there to Kwaj a few
days before New Year's Eve. The new stage should arrive at Kwaj in
about a week, whereupon we will switch it out with the damaged unit,
which will be sent back to California for repair. The repair is not
particularly difficult or expensive, but can only be done properly in a
factory setting.
What Was the Problem?
As previously reported, we traced the problem to failure of an
electronic component in one of the first stage fuel tank pressurization
valves. Although we have triple redundant pressure sensors and dual
redundant pressurization valves, when this component shorted, it caused
the valve controller board to reboot, effectively eliminating the
redundancy.
This is the first time in 3.5 years of hard testing that we have ever
seen this happen. Moreover, the component in question has a cycle life
and power rating far in excess of the theoretical load that it should
see. To address this specific problem, we are replacing the component
with one that has a quasi-infinite lifespan and taking a few other
steps that will isolate any issue with this component if it goes wrong
in the future.
However, as I mentioned in an earlier update, we are not simply going
to address this particular point problem and then merrily jump back
into a countdown sequence. Throughout January, the SpaceX team will be
doing another full review of vehicle systems, including propulsion,
structures, avionics, software and ground support systems. We will be
conducting additional engine tests, stage separation tests and avionics
tests to once again attempt to flush out any issues. Even if we find
nothing, the exercise is worthwhile.
Wind Delays Suck (Literally)
It is worth noting that we would have caught the problem without any
damage to the vehicle if we had entered the final countdown sequence as
planned. The sucked in tank damage only occurred because we partly
drained the fuel tank due to the hold for high winds.
High winds are not a limitation of the rocket, which is designed to be
essentially "all weather" and handle ground winds in excess of 50 mph
(watch out for flying coconuts!). The ground winds limitation is
actually due to the need to avoid a collision with the launch stand
hold down arms, which grab the rocket at the base of the fuel tank, as
the rocket lifts off.
To alleviate this problem, we have redesigned the launch stand so that
the hold down arms retract out of the way on liftoff, activated by a
breakwire. This gives us something very close to 100% winds
availability from Kwaj. The retraction force is low, so even if there
were an early activation of the actuator, it would not damage the
rocket.
Another bothersome problem is the high rate of liquid oxygen (LOX)
boiloff. This is not surprising when LOX is at -300F and there is a
stiff wind impinging on the vehicle at 85F. To minimize boiloff, we
will wrap the LOX tank in low cost cryo insulation attached with velcro
straps that tear away on liftoff.
Lessons Learned on F1 Apply to F9
The challenges to date I think vindicate the strategy of building a
small launch vehicle before a large one. If we had started out with an
F9 class vehicle, the cost of every mistake would be multiplied by as
much as an order of magnitude. As it is, we are able to overcome
problems comparatively quickly and cheaply.
With the benefit of lessons learned on F1, it is taking far less time,
effort and money to create F9. Despite the distraction of the F1
launch countdowns, I still anticipate a flight F9 first stage firing
later this year and a maiden launch in late 2007.
Great Expectations Falcon 1 on the Omelek Launch Pad
Those familiar with the launch business will know that countdown scrubs
are a way of life. It's often said that the safest time to schedule
your vacation is around launch day and that's true more often than not.
Even rockets that have launched hundreds of times from launch pads
that are in heavy use have multiple scrubs. Not too long ago, there
was a Titan launch that had eleven scrubs and Delta launch that had
six.
Reasons range from hard to avoid technical glitches, like the Shuttle
fuel sensor malfunction on its last launch attempt, to silly false
alarms. A Titan countdown was once aborted when someone spotted a "bag
of suspicious liquid" on the mobile service tower. It turned out that
the latrine had simply been a bridge too far for one of the
technicians.
Given that Falcon 1 is an all new rocket and is launching from an all
new launch pad on a remote tropical island, countdown scrubs in the
first few attempts were very likely. As it is, we have had one abort
due to a launch pad issue and one due to the rocket. If this next
attempt succeeds in getting to t-zero, SpaceX will be reasonably
fortunate in the scheme of things.
---Elon---
Just my $0.02
Space Cadet
derwetzelsDASHspacecadetATyahooDOTcom
Moon Society - St. Louis Chapter
http://www.moonsociety.org/chapters/stlouis/
There is only one (maybe 2) basic core reasons for humans to go
beyond LEO, That is for the establishment of space settlements or a
space based civilization. Everything else are details.
Gary Gray 11/9/2005
richard schumacher
> What Was the Problem?
> As previously reported, we traced the problem to failure of an
> electronic component in one of the first stage fuel tank pressurization
> valves. Although we have triple redundant pressure sensors and dual
> redundant pressurization valves, when this component shorted, it caused
> the valve controller board to reboot, effectively eliminating the
> redundancy.
Three valves + one controller in common with all three = no redundancy.
> However, as I mentioned in an earlier update, we are not simply going
> to address this particular point problem and then merrily jump back
> into a countdown sequence. Throughout January, the SpaceX team will be
> doing another full review of vehicle systems, including propulsion,
> structures, avionics, software and ground support systems. We will be
> conducting additional engine tests, stage separation tests and avionics
> tests to once again attempt to flush out any issues. Even if we find
> nothing, the exercise is worthwhile.
Especially worthwhile if they discover any more previously untested
hardware, software, or procedures.
> It is worth noting that we would have caught the problem without any
> damage to the vehicle if we had entered the final countdown sequence as
> planned. The sucked in tank damage only occurred because we partly
> drained the fuel tank due to the hold for high winds.
Would not the suck-in then have occurred during flight, thus destroying
the vehicle? Surely the on-board pump drains the tank at least as
rapidly as can any ground pumps.
> To alleviate this problem, we have redesigned the launch stand so that
> the hold down arms retract out of the way on liftoff, activated by a
> breakwire. This gives us something very close to 100% winds
> availability from Kwaj. The retraction force is low, so even if there
> were an early activation of the actuator, it would not damage the
> rocket.
Presumably these will be tested before the launch attempt.
Derek Lyons
>As previously reported, we traced the problem to failure of an
>electronic component in one of the first stage fuel tank pressurization
>valves. Although we have triple redundant pressure sensors and dual
>redundant pressurization valves, when this component shorted, it caused
>the valve controller board to reboot, effectively eliminating the
>redundancy.
If there is only one controller - it doesn't matter much if you have
one sensor and valve or a hundred. There isn't any redundancy.
>Another bothersome problem is the high rate of liquid oxygen (LOX)
>boiloff. This is not surprising when LOX is at -300F and there is a
>stiff wind impinging on the vehicle at 85F. To minimize boiloff, we
>will wrap the LOX tank in low cost cryo insulation attached with velcro
>straps that tear away on liftoff.
This sounds like a bad idea.
D.
--
Touch-twice life. Eat. Drink. Laugh.
-Resolved: To be more temperate in my postings.
Oct 5th, 2004 JDL
Jake McGuire
> >Although we have triple redundant pressure sensors and dual
> >redundant pressurization valves, when this component shorted, it caused
> >the valve controller board to reboot, effectively eliminating the
> >redundancy.
>
> If there is only one controller - it doesn't matter much if you have
> one sensor and valve or a hundred. There isn't any redundancy.
Well, there's not FULL redundancy. If the valve controller was able to
handle failing valves, and had a higher reliability than the valves in
question, even with one controller the system would be more reliable.
I'd say this is just another example of people forgetting that
redundancy requires not only backup components but the ability to
reliably switch to them under failure conditions. I saw many amusing
examples of the same problem with backup power supplies at data centers
back during the dot-com days.
> >Another bothersome problem is the high rate of liquid oxygen (LOX)
> >boiloff. This is not surprising when LOX is at -300F and there is a
> >stiff wind impinging on the vehicle at 85F. To minimize boiloff, we
> >will wrap the LOX tank in low cost cryo insulation attached with velcro
> >straps that tear away on liftoff.
>
> This sounds like a bad idea.
Agreed. It's a small launcher, so it's not only going to have a higher
surface area to volume ratio, but it's going to have thinner tank
walls. More heat transfer, more boiloff. I find it hard to believe
that LOX (even on Kwajalein) and pressurization valve cycles are so
expensive that bigger ground tanks aren't the answer. Big pieces
falling off and flying around in a windy environment don't sound good
to me.
My estimate for the chances of success on the first Falcon launch are
dropping rapidly.
-jake
Derek Lyons
>Derek Lyons wrote:
>> >Although we have triple redundant pressure sensors and dual
>> >redundant pressurization valves, when this component shorted, it caused
>> >the valve controller board to reboot, effectively eliminating the
>> >redundancy.
>>
>> If there is only one controller - it doesn't matter much if you have
>> one sensor and valve or a hundred. There isn't any redundancy.
>
>Well, there's not FULL redundancy. If the valve controller was able to
>handle failing valves, and had a higher reliability than the valves in
>question, even with one controller the system would be more reliable.
"More reliable" != "Redundant". One of something is never redundant,
period.
>I'd say this is just another example of people forgetting that
>redundancy requires not only backup components but the ability to
>reliably switch to them under failure conditions. I saw many amusing
>examples of the same problem with backup power supplies at data centers
>back during the dot-com days.
An utterly meaningless statement - since there was no redundancy and
no backups. You can't switch between units if there is only one.
Jake McGuire
> "Jake McGuire" <jamc...@yahoo.com> wrote:
>
> >Derek Lyons wrote:
> >> >Although we have triple redundant pressure sensors and dual
> >> >redundant pressurization valves, when this component shorted, it caused
> >> >the valve controller board to reboot, effectively eliminating the
> >> >redundancy.
> >>
> >> If there is only one controller - it doesn't matter much if you have
> >> one sensor and valve or a hundred. There isn't any redundancy.
> >
> >Well, there's not FULL redundancy. If the valve controller was able to
> >handle failing valves, and had a higher reliability than the valves in
> >question, even with one controller the system would be more reliable.
>
> "More reliable" != "Redundant". One of something is never redundant,
> period.
Right. But there were three pressure sensors and two pressurization
valves. What word would you use to describe the property of the
pressurization system such that if one sensor fails, the whole system
can continue to function due to the presence of other sensors, if not
"redundant"?
> >I'd say this is just another example of people forgetting that
> >redundancy requires not only backup components but the ability to
> >reliably switch to them under failure conditions. I saw many amusing
> >examples of the same problem with backup power supplies at data centers
> >back during the dot-com days.
>
> An utterly meaningless statement - since there was no redundancy and
> no backups. You can't switch between units if there is only one.
What's meaningless about it? SpaceX thought that their pressurization
valves were redundant. They certainly had two of them, and I'm
assuming that their design was such that if one of the valves stopped
responding, it would fail closed, and then they could switch to the
backup and continue to regulate tank pressure. Hence, redundancy
against at least some types of valve failure.
Unfortunately, the valve controller couldn't handle the valve failure
that actually happened (failing short), and rebooted into an
inappropriate state. It's not clear if the valve failing short was
unexpected, or if the controller's failure to handle it was unexpected,
but it is clear that they had another valve that should have been able
to regulate the tank pressure but didn't.
-jake
Derek Lyons
>Derek Lyons wrote:
>> "Jake McGuire" <jamc...@yahoo.com> wrote:
>>
>> >Derek Lyons wrote:
>> >> >Although we have triple redundant pressure sensors and dual
>> >> >redundant pressurization valves, when this component shorted, it caused
>> >> >the valve controller board to reboot, effectively eliminating the
>> >> >redundancy.
>> >>
>> >> If there is only one controller - it doesn't matter much if you have
>> >> one sensor and valve or a hundred. There isn't any redundancy.
>> >
>> >Well, there's not FULL redundancy. If the valve controller was able to
>> >handle failing valves, and had a higher reliability than the valves in
>> >question, even with one controller the system would be more reliable.
>>
>> "More reliable" != "Redundant". One of something is never redundant,
>> period.
>
>Right. But there were three pressure sensors and two pressurization
>valves. What word would you use to describe the property of the
>pressurization system such that if one sensor fails, the whole system
>can continue to function due to the presence of other sensors, if not
>"redundant"?
The key issue is that the pressurization *system* isn't redundant. If
you have a single point of failure, then you don't have a redundant
system.
>> >I'd say this is just another example of people forgetting that
>> >redundancy requires not only backup components but the ability to
>> >reliably switch to them under failure conditions. I saw many amusing
>> >examples of the same problem with backup power supplies at data centers
>> >back during the dot-com days.
>>
>> An utterly meaningless statement - since there was no redundancy and
>> no backups. You can't switch between units if there is only one.
>
>What's meaningless about it? SpaceX thought that their pressurization
>valves were redundant.
What's meaningless? The Falcon 1 didn't have a backup component to
switch to. One unit failed - and it brought down the entire system.
Jake McGuire
> "Jake McGuire" <jamc...@yahoo.com> wrote:
>
> >Derek Lyons wrote:
> >> "Jake McGuire" <jamc...@yahoo.com> wrote:
> >>
> >> >Derek Lyons wrote:
> >> >> >Although we have triple redundant pressure sensors and dual
> >> >> >redundant pressurization valves, when this component shorted, it caused
> >> >> >the valve controller board to reboot, effectively eliminating the
> >> >> >redundancy.
> >> >>
> >> >> If there is only one controller - it doesn't matter much if you have
> >> >> one sensor and valve or a hundred. There isn't any redundancy.
> >> >
> >> >Well, there's not FULL redundancy. If the valve controller was able to
> >> >handle failing valves, and had a higher reliability than the valves in
> >> >question, even with one controller the system would be more reliable.
> >>
> >> "More reliable" != "Redundant". One of something is never redundant,
> >> period.
> >
> >Right. But there were three pressure sensors and two pressurization
> >valves. What word would you use to describe the property of the
> >pressurization system such that if one sensor fails, the whole system
> >can continue to function due to the presence of other sensors, if not
> >"redundant"?
>
> The key issue is that the pressurization *system* isn't redundant. If
> you have a single point of failure, then you don't have a redundant
> system.
No one has claimed that the pressurization system was redundant. He
said they had redundant components, but when one failed it took out a
related, non-redundant component, rendering the component-level
redundancy meaningless.
-jake
Sander Vesik
>
> Right. But there were three pressure sensors and two pressurization
> valves. What word would you use to describe the property of the
> pressurization system such that if one sensor fails, the whole system
> can continue to function due to the presence of other sensors, if not
> "redundant"?
>
"having duplicated sensors". For the system to be redundant, the
failure of *any* one component must be survivable. To label the whole
system as redundant based on duplication of some component is not just
stupid, its irresponsible. Even more so if the single point of failure
is such a critical component as the controller.
> -jake
Henry Spencer
Derek Lyons <fair...@gmail.com> wrote:
>>...Although we have triple redundant pressure sensors and dual
>>redundant pressurization valves, when this component shorted, it caused
>>the valve controller board to reboot, effectively eliminating the
>>redundancy.
>
>If there is only one controller - it doesn't matter much if you have
Actually, it does, because the moving parts are much the most likely
things to fail.
The gory details of exactly how this screwup happened are not clear to me,
but bear in mind that redundant electronics often don't buy you very much,
because electronics failures nowadays tend to be design errors, which
typically affect all "redundant" modules identically (remember the first
Ariane 5, lost when both IMU computers crashed due to the same bug).
>>...To minimize boiloff, we
>>will wrap the LOX tank in low cost cryo insulation attached with velcro
>>straps that tear away on liftoff.
>
>This sounds like a bad idea.
Agreed. They're all too likely to find their insulation frozen to the
tank. They're starting down the road several groups have followed in the
past, which typically ends in a change of approach after the full
complexity of purges etc. sinks in.
--
spsystems.net is temporarily off the air; | Henry Spencer
mail to henry at zoo.utoronto.ca instead. | he...@spsystems.net
Pete Lynn
news:IsxqF...@spsystems.net...
>
> Agreed. They're all too likely to find their insulation
> frozen to the tank. They're starting down the road
> several groups have followed in the past, which
> typically ends in a change of approach after the full
> complexity of purges etc. sinks in.
But would not such insulation be constructed like a tent fly without
direct contact to the tank? Especially if it only need help mitigate
increased heat transfer due to wind. This should not be the least bit
difficult or expensive.
Pete.
Tom Cuddihy
Don't bother explaining, Jake. Derek's a nuke and thinks all systems of
whatever type must meet nuclear failure criteria. Cost is no object.
Tom
Tom Cuddihy
agree, this is LOX, not LH2.
Tom
Henry Spencer
Pete Lynn <pe...@peterlynnkites.com> wrote:
>> Agreed. They're all too likely to find their insulation
>> frozen to the tank. They're starting down the road
>
>But would not such insulation be constructed like a tent fly without
>direct contact to the tank?
"wrap the LOX tank" sounds to me like they're talking about direct contact.
I agree that it would make sense to try to set up some sort of windbreak,
rather than actually insulating the tank, but it sounds like the latter is
what they're planning.
Derek Lyons
>Don't bother explaining, Jake. Derek's a nuke and thinks all systems of
>whatever type must meet nuclear failure criteria. Cost is no object.
If you ever pull your head out of your ass and actually bother to read
what I've written - you'll find I'm not a nuke, and have never claimed
to be.
Oh, wait - that would require actually thinking and learning
something.
Never mind.
Derek Lyons
>The gory details of exactly how this screwup happened are not clear to me,
>but bear in mind that redundant electronics often don't buy you very much,
>because electronics failures nowadays tend to be design errors, which
>typically affect all "redundant" modules identically (remember the first
>Ariane 5, lost when both IMU computers crashed due to the same bug).
That's very true Henry, but it misses the point. What I'm objecting
to is the statement by SpaceX that "the [single] controller crashed,
and we lost redundancy". If you have a single point of failure, you
never had the redundancy in the first place.
snidely
Derek Lyons wrote:
> What I'm objecting
> to is the statement by SpaceX that "the [single] controller crashed,
> and we lost redundancy". If you have a single point of failure, you
> never had the redundancy in the first place.
They had downstream redundancy (sensors and valves), but did not have
redundancy in the whole string. Their claim isn't invalid, just
narrow.
/dps
John Schilling
Except insofar as it is novel, and novelty is not something you want
to deal with when you're pressed for time.
It would be a nice side project, for someone with a working launcher,
to say "now how can we tent this thing to keep LOX boiloff down on
windy days?" It's a bit worrisome that someone considers this, rather
than Extra LOX, to be enabling technology for their *first* launch.
--
*John Schilling * "Anything worth doing, *
*Member:AIAA,NRA,ACLU,SAS,LP * is worth doing for money" *
*Chief Scientist & General Partner * -13th Rule of Acquisition *
*White Elephant Research, LLC * "There is no substitute *
*schi...@spock.usc.edu * for success" *
*661-951-9107 or 661-275-6795 * -58th Rule of Acquisition *
Rüdiger Klaehn
controller crashed,
and we lost redundancy" implies that there was some redundancy in the
controller, which was not the case.
But in the updates they always made it perfectly clear that the falcon
1 has no redundancy in the electronics, but is "single string": They
plan to have more redundancy for the falcon 5 and 9 in order to
increase reliability for manned missions. For example, the falcon 9
will have three flight computers with "voting".
I really don't see why they change so much about at this point. I think
the best way to handle the LOX boiloff problem would be to have more
LOX, and the best way to handle the wind problem would be to launch in
lower winds. They still have a "development mindset", constantly
improving their systems and procedures. Maybe they should let another
team that has a more conservative mindset handle the launch.
That said, so far their problems have been relatively minor for a brand
new launcher. I was really relieved that there was no structural error
in the first stage.
Jake McGuire
> he...@spsystems.net (Henry Spencer) wrote:
>
> >The gory details of exactly how this screwup happened are not clear to me,
> >but bear in mind that redundant electronics often don't buy you very much,
> >because electronics failures nowadays tend to be design errors, which
> >typically affect all "redundant" modules identically (remember the first
> >Ariane 5, lost when both IMU computers crashed due to the same bug).
>
> That's very true Henry, but it misses the point. What I'm objecting
> to is the statement by SpaceX that "the [single] controller crashed,
> and we lost redundancy". If you have a single point of failure, you
> never had the redundancy in the first place.
It's not just that the controller crashed that prompted this statement.
Their electronics are single string; they know that if the computer
takes a dump they're screwed.
But they thought they were protected against valve failure, by way of
having multiple valves and a controller that would switch from a failed
one to a working one - redundant valevs. It was the valve failing and
taking the controller with it that caught them by surprise, and meant
that they didn't have the limited redundancy that they thought they
did.
-jake
Pete Lynn
news:dq6gt...@drn.newsguy.com...
> > tent fly without direct contact to the tank?
> > Especially if it only need help mitigate increased
> > heat transfer due to wind. This should not be the
> > least bit difficult or expensive.
>
> Except insofar as it is novel, and novelty is not
> something you want to deal with when you're pressed
> for time.
It is sad and amusing to think that tents, which probably predate
civilization, are considered novel to the space industry.
Pete.