MaverickSawyer
Acolyte of the Probe
Perhaps because we're actually in touch with reality?
There is no risk what-so-ever associated with trying to soft land the 1st stage. The 2nd stage will already be on it's way to orbit.
the first Ariane 5 flight also failed just because of software, that should not be active.
Based on the extensive documentation and data on the Ariane 501 failure made available to the Board, the following chain of events, their inter-relations and causes have been established, starting with the destruction of the launcher and tracing back in time towards the primary cause.
- The launcher started to disintegrate at about H0 + 39 seconds because of high aerodynamic loads due to an angle of attack of more than 20 degrees that led to separation of the boosters from the main stage, in turn triggering the self-destruct system of the launcher.
- This angle of attack was caused by full nozzle deflections of the solid boosters and the Vulcain main engine.
- These nozzle deflections were commanded by the On-Board Computer (OBC) software on the basis of data transmitted by the active Inertial Reference System (SRI 2). Part of these data at that time did not contain proper flight data, but showed a diagnostic bit pattern of the computer of the SRI 2, which was interpreted as flight data.
- The reason why the active SRI 2 did not send correct attitude data was that the unit had declared a failure due to a software exception.
- The OBC could not switch to the back-up SRI 1 because that unit had already ceased to function during the previous data cycle (72 milliseconds period) for the same reason as SRI 2.
- The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected.
- The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose.
- The alignment function is operative for 50 seconds after starting of the Flight Mode of the SRIs which occurs at H0 - 3 seconds for Ariane 5. Consequently, when lift-off occurs, the function continues for approx. 40 seconds of flight. This time sequence is based on a requirement of Ariane 4 and is not required for Ariane 5.
- The Operand Error occurred due to an unexpected high value of an internal alignment function result called BH, Horizontal Bias, related to the horizontal velocity sensed by the platform. This value is calculated as an indicator for alignment precision over time.
- The value of BH was much higher than expected because the early part of the trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably higher horizontal velocity values.
Again, the problem is not what happens AFTER the second stage separated. The problem is, that you have to launch with the modification. Even if it is just software, even if it is just software that should not be active... the first Ariane 5 flight also failed just because of software, that should not be active.
No, that's incorrect. The software it was using was the wrong software.
You do know that the shuttle needed a few software changes for each launch to cater for various payloads?
That is a fallacious argument.
If everything must be flown before it is allowed to be flown how does one ever fly anything new?
From my end your argument appears to be space flight is risky and thus requires prior testing. Testing is risky therefore our tests require prior testing. Testing for the tests is risky therefore...
How far down do the turtles go?
That is your argument, not mine. My argument is, that such changes can't be done as piggy-back option late in the development of a new untested rocket. You need to start it soon and inclusive. Or in the development of the next iteration, after the first few regular flights.
And its turtles all the way down to the Elephants.
Please explain the difference then. The above characterization does not appear to gel with the reality.
Difference: Have no late major changes after definition phase vs adding new features late in development. The latter one is responsible for 45% of all project failures.
Where are you getting this whole "major changes late in development" idea?
SpaceX announced their intention to develop a propulsive landing 1st stage booster long before they publicly announced F9 v1.1 and it's probably fair to assume that a good deal of definition and design work occurred before the public announcement.
Which brings us back to my earlier point. So long as the 2nd stage is on it's way, SpaceX has absolutely nothing to loose from playing R/C rocket with the 1st stage. Infact it is exactly the sort of testing that the SpaceX nay-sayers say they need to do more of.
Announcing and developing are two things. There was never such a feature mentioned at all in the Falcon 9 1.1 plans.
Luckily, such an attitude is already punished in Orbiter. But you can of course claim now, that developing Orbiter add-ons is much harder than building a real rocket.
Are you saying that when you develop an addon that you don't plan ahead or leave openings in your code for features that you'd like to add to later versions?
I did not claim anything. You are one that claims they did not designed and tested for this maneuver from day one. You claim that they started thinking about it only recently.Logical fallacy ahead. You demand that I proof that something I suggest is not. That is something we should better leave to the moon landing hoaxers and try the opposite: Positive proofs.
Any evidence they started it at beginning of 2013? Or you will say again "I don't have to prove it"?(...)At the beginning of the year, they reported to the powers that be, presented their findings. And the powers had been impressed by the recovery test idea and decided to push ahead.(...)
Dont tell me this is your whole argument for "they started it just recently".By the fact that Musk announced it now
Dont tell me this is your whole argument for "they started it just recently".
Do you have a better one, aside of: "I strongly believe that SpaceX doesn't do something stupid, they would NEVER do that."
This isn't a new idea for them. Since SpaceX's very beginnings, they have talked about recovering and reusing at least the first stages of their rockets. What's been conspicuously lacking is any visible progress toward that. Now this might change.
SpaceX HAVE been planing first stage recovery since DAY ONE.
Source: http://www.newscientist.com/blogs/shortsharpscience/2011/09/falcon-rockets-to-land-on-thei.html
Dated? September 2011
So if they had been planing it way back then and at that point, as per the article, had been planing it for sometime this cannot be called a new idea.
What Dennis is trying to point out is that for a machine in a new configuration, even small errors in assumptions on using systems from other existing machines can led to disastrous results...
Not with the boost back though. (back in the Falcon 1 and the first few Falcon 9 days it was envisioned as simply dumping the first stage down-range with parachutes and recovery done at sea) Unfortunately it is difficult to see if v1.1 is designed right from the start with boost-back in mind, since its lineage from earlier F9 evolution options (like the smaller "Falcon 9 Block II") is extremely unclear.
Wasn't the boost-back optioned only surfaced after the first Falcon 9 flight? :idk:
SpaceX HAVE been planing first stage recovery since DAY ONE.
Source: http://www.newscientist.com/blogs/shortsharpscience/2011/09/falcon-rockets-to-land-on-thei.html
Dated? September 2011
So if they had been planing it way back then and at that point, as per the article, had been planing it for sometime this cannot be called a new idea.