Author Topic: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION  (Read 786524 times)

Offline deruch

  • Senior Member
  • *****
  • Posts: 2422
  • California
  • Liked: 2006
  • Likes Given: 5634
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1680 on: 04/09/2018 06:13 pm »
There is no way to delay reentry.  It flies a preprogramed course flight profile regardless of what they may see.
Then what happened on CRS-1?  The second burn for Orbcomm was cancelled from the ground.  That tells me the programming can be preempted from the ground.
Incorrect. The burn was not cancelled from the ground. It was cancelled by the on-board flight computer, based on pre-programmed instructions to NOT initiate the second burn if there is insufficient propellant to complete the mission.

The on-board computer keeps track of how long the first burn was for completion of the primary mission (getting Cargo Dragon on its way to ISS). Orbcomm was the secondary mission. Based on the extended burn required to get the target delta-V for Cargo Dragon it was clear to the onboard-computer that there was insufficient propellant left for the second burn. And thus that second burn was not initiated.

IIRC, it wasn't that there was insufficient propellant left for the second burn but rather that they were required to maintain a strict amount of additional margin beyond what was actually required for the burn.  This was where there was a shortfall.  So, they could have done the burns fine (assuming they went nominally) but would have ended up with less propellant remaining than was required by NASA's safety restrictions to be kept for contingencies on the mission.  My reading between the lines was that SpaceX felt the margin required was somewhat excessive, but as it was their first CRS delivery mission and still early in the F9's operational life NASA wasn't willing to take much risk.
Shouldn't reality posts be in "Advanced concepts"?  --Nomadd

Offline Star One

  • Senior Member
  • *****
  • Posts: 13997
  • UK
  • Liked: 3974
  • Likes Given: 220
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1681 on: 04/09/2018 07:40 pm »
https://twitter.com/jeff_foust/status/983319308943200258?s=20

Quote
Jeff Foust
@jeff_foust
Wonder how many people who blamed SpaceX for the failed Zuma launch will offer mea culpas now that investigations reportedly show a Northrop-provided payload adapter was to blame?

I don’t think any more need to be said in relation to this bit.

Offline Star One

  • Senior Member
  • *****
  • Posts: 13997
  • UK
  • Liked: 3974
  • Likes Given: 220
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1682 on: 04/09/2018 07:42 pm »
Google found this non-paywalled copy of above quote here

Nothing there except a search box?

Offline speedevil

  • Senior Member
  • *****
  • Posts: 4406
  • Fife
  • Liked: 2762
  • Likes Given: 3369
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1683 on: 04/09/2018 07:55 pm »
There is no way to delay reentry.  It flies a preprogramed course flight profile regardless of what they may see.

Clearly there are parts of the trajectory that must be preprogrammed and changing stuff mid-flight is actively dangerous and happening so fast it needs to be preprogrammed - boost phase. And it needs to be secure.

But having the capability to debug in-flight seems like an odd capability to leave out - if only that it can help get you to the nominal flight profile after hardware failures. As an obvious example, the stage may not if Zuma had been somewhat further out, been able to reenter with it attached as it had inadequate delta-v.

Is this legislatively required?

Offline WindnWar

  • Full Member
  • ****
  • Posts: 556
  • South Carolina
  • Liked: 333
  • Likes Given: 1811
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1684 on: 04/09/2018 08:25 pm »
There is no way to delay reentry.  It flies a preprogramed course flight profile regardless of what they may see.

Clearly there are parts of the trajectory that must be preprogrammed and changing stuff mid-flight is actively dangerous and happening so fast it needs to be preprogrammed - boost phase. And it needs to be secure.

But having the capability to debug in-flight seems like an odd capability to leave out - if only that it can help get you to the nominal flight profile after hardware failures. As an obvious example, the stage may not if Zuma had been somewhat further out, been able to reenter with it attached as it had inadequate delta-v.

Is this legislatively required?

I would think that unless such control can be proven secure, especially for such a payload, even if it existed for a commercial sat, it would probably be required to be disabled for a mission like Zuma.

But we are discussing a capability that as far as any of us knows, doesn't exist currently unless someone can state that it does.

I am curious why a third party adapter was used and modified rather than modifying SpaceX's standard adapter if need be. Were the vibration and shock dampening stated as the reason for using the third party adapter not possible to achieve with SpaceX's adapter? How much shock does an adapter impart compared to the launch environment? Just staging alone would seem to be more of an issue than payload sep... To date SpaceX has launched many of their payload adapters with no failures to date.

Offline rst

  • Full Member
  • ***
  • Posts: 347
  • Liked: 127
  • Likes Given: 0
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1685 on: 04/09/2018 08:33 pm »
Basic run-down of the article (for what it's worth):

- NG bought a payload adapter from a third party.
- NG modified the payload adapter to suit Zuma.
- NG tested the modified payload adapter with positive results
- Modified adapter however failed to function properly in zero-G
- Both government and industry investigation teams have reached same conclusion: NG is to blame for loss of Zuma

Thanks for the rundown. The non-paywall article also speculates that Zuma costs $3.5B to develop and build, which is a number that I have not seen around before. Maybe I missed it.

Hindsight is 20/20, but if that $3.5B budget is accurate, it might not have been a total budget-buster for them to get a test launch of the adapter and instrumented test articles (before launching the final payload), just to verify that it all performed as expected under actual launch conditions and stresses. (Or not.)

(This would presumably be more expensive just as a launch than SpaceX standard commercial rates, due to security concerns, etc., to which you'd have to add the cost of the second adapter, test articles, etc. And $150M or so -- wild-ass guess -- is not exactly cheap as an insurance premium. But neither is the program as a whole...)

Offline R.Simko

  • Full Member
  • ***
  • Posts: 320
  • Liked: 9
  • Likes Given: 24
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1686 on: 04/09/2018 08:39 pm »
Two questions.

1.  If NG is determined to be responsible for this satellite failure, will it cost them any money?

2.  Will this article now be read into the congressional record, as was done with SX?


Online AnalogMan

  • Member
  • Senior Member
  • *****
  • Posts: 3431
  • Cambridge, UK
  • Liked: 1602
  • Likes Given: 50
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1687 on: 04/09/2018 08:49 pm »
Google found this non-paywalled copy of above quote here

Nothing there except a search box?

This link may work for a little while (give the page few seconds to fully load).

Offline speedevil

  • Senior Member
  • *****
  • Posts: 4406
  • Fife
  • Liked: 2762
  • Likes Given: 3369
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1688 on: 04/09/2018 08:59 pm »
Having the capability to debug in-flight seems like an odd capability to leave out - if only that it can help get you to the nominal flight profile after hardware failures. As an obvious example, the stage may not if Zuma had been somewhat further out, been able to reenter with it attached as it had inadequate delta-v.

Is this legislatively required?

I would think that unless such control can be proven secure, especially for such a payload, even if it existed for a commercial sat, it would probably be required to be disabled for a mission like Zuma.

But we are discussing a capability that as far as any of us knows, doesn't exist currently unless someone can state that it does.

I'm not arguing it does exist, just that it seems far from clear it can't be there, unless there are specific reasons mandating its absence.

Offline docmordrid

  • Senior Member
  • *****
  • Posts: 6334
  • Michigan
  • Liked: 4207
  • Likes Given: 2
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1689 on: 04/09/2018 09:00 pm »
CNBC has a non-paywalled story

Link...
« Last Edit: 04/09/2018 09:00 pm by docmordrid »
DM

Offline Norm38

  • Full Member
  • ****
  • Posts: 1696
  • Liked: 1272
  • Likes Given: 2317
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1690 on: 04/09/2018 09:33 pm »
However this scenario is an argument for having the ability to interrupt/override/update program, before deorbit begins.

I would say it's more of an argument toward ensuring that your payload adapter actually... works.

Sure, but this is also going to be a crew rated system.  If Crewed Dragon fails to detach from the second stage, it doesn't do anyone any good to say "well, should have designed it better", as the crew are dragged down to their deaths by the pre-programmed second stage.  There had better be an override, so why not offer it to all payloads?

Offline rpapo

However this scenario is an argument for having the ability to interrupt/override/update program, before deorbit begins.

I would say it's more of an argument toward ensuring that your payload adapter actually... works.

Sure, but this is also going to be a crew rated system.  If Crewed Dragon fails to detach from the second stage, it doesn't do anyone any good to say "well, should have designed it better", as the crew are dragged down to their deaths by the pre-programmed second stage.  There had better be an override, so why not offer it to all payloads?
The attachment of the Dragon to the second stage is quite different from the attachment of any other payload.
Following the space program since before Apollo 8.

Offline Norm38

  • Full Member
  • ****
  • Posts: 1696
  • Liked: 1272
  • Likes Given: 2317
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1692 on: 04/09/2018 10:01 pm »
It doesn't matter if it's different. And I don't care what the RPN numbers are on the DFMEA.  The Dragon CAN fail to detach.  And if it CAN, then the 2nd stage MUST be able to abort the deorbit burn.  So they have to plan for that anyways, and can provide that option to all payloads.

Given what just happened to Zuma, what customer would say "No, that's fine, I don't want the abort option"?

Offline WindnWar

  • Full Member
  • ****
  • Posts: 556
  • South Carolina
  • Liked: 333
  • Likes Given: 1811
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1693 on: 04/09/2018 10:08 pm »

However this scenario is an argument for having the ability to interrupt/override/update program, before deorbit begins.

I would say it's more of an argument toward ensuring that your payload adapter actually... works.

Sure, but this is also going to be a crew rated system.  If Crewed Dragon fails to detach from the second stage, it doesn't do anyone any good to say "well, should have designed it better", as the crew are dragged down to their deaths by the pre-programmed second stage.  There had better be an override, so why not offer it to all payloads?
The attachment of the Dragon to the second stage is quite different from the attachment of any other payload.

Not to mention the crew system has to have a means to abort and that abort system will obviously include separation from the second stage, or from the trunk if need be. Any overriding of pre-planned burns of the second stage can be part of the abort system, and would not necessarily exist without Dragon. It also would not need to be able to be triggered from the ground, which has obvious security risks.

It doesn't matter if it's different. And I don't care what the RPN numbers are on the DFMEA.  The Dragon CAN fail to detach.  And if it CAN, then the 2nd stage MUST be able to abort the deorbit burn.  So they have to plan for that anyways, and can provide that option to all payloads.

Given what just happened to Zuma, what customer would say "No, that's fine, I don't want the abort option"?

So equating abort options part of Crew Dragon launches to a option for non crew launches doesn't necessarily add up.

Offline Norm38

  • Full Member
  • ****
  • Posts: 1696
  • Liked: 1272
  • Likes Given: 2317
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1694 on: 04/09/2018 10:14 pm »
If a failed Dragon separation hung up mechanically but the break wires had severed, could Dragon still command the second stage wirelessly?  If not, the 2nd stage isn't off the hook.

Offline WindnWar

  • Full Member
  • ****
  • Posts: 556
  • South Carolina
  • Liked: 333
  • Likes Given: 1811
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1695 on: 04/09/2018 10:17 pm »
The other thing missing from the musing of whether it could be commanded to not re-enter, there is a limited amount of time the second stage can stay on orbit, if your payload adapter fails, unless you can come up with a fix asap that doesn't risk the second stage colliding with the payload or putting the payload into a spin that could damage it or send it out of control, not commanding a re-entry only buys you a limited amount of time before the stage batteries run out and the stage has to vent it's propellent.

Essentially the options would be very limited, with a limited time window, with a lot of potential debris risks.

How often do payload adapters fail? Is doesn't seem like a common failure.

Offline WindnWar

  • Full Member
  • ****
  • Posts: 556
  • South Carolina
  • Liked: 333
  • Likes Given: 1811
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1696 on: 04/09/2018 10:23 pm »
If a failed Dragon separation hung up mechanically but the break wires had severed, could Dragon still command the second stage wirelessly?  If not, the 2nd stage isn't off the hook.

It doesn't matter, again, Dragon is attached to the trunk and the trunk is attached to the second stage, either could separate and while the mission would be affected if you had to separate the trunk your ability to separate essentially has redundancy. If both fail you have far worse issues to deal with. As long as you can separate the trunk you would abort after a reaching a place in orbit suitable to re-enter.

Your also looking at attachments that due to their nature will probably have multiple redundancies.

Offline Kabloona

  • Senior Member
  • *****
  • Posts: 4846
  • Velocitas Eradico
  • Fortress of Solitude
  • Liked: 3429
  • Likes Given: 741
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1697 on: 04/09/2018 10:40 pm »

I am curious why a third party adapter was used and modified rather than modifying SpaceX's standard adapter if need be. Were the vibration and shock dampening stated as the reason for using the third party adapter not possible to achieve with SpaceX's adapter? How much shock does an adapter impart compared to the launch environment? Just staging alone would seem to be more of an issue than payload sep... To date SpaceX has launched many of their payload adapters with no failures to date.

I'm guessing you were referring to this quote:

Quote
The unique design of Zuma, according to officials, means it was built in such a way that made it particularly fragile. Northrop reportedly modified its payload adapter to help absorb vibrations that might damage the satellite.

https://www.cnbc.com/2018/04/09/northrop-grumman-reportedly-at-fault-for-loss-of-zuma-satellite.html

Re your question about how much shock the adapter imparts vs. the launch environment, it's impossible to know exactly which "vibrations" they were trying to damp. It all depends on the natural modes of the payload and which frequencies it was most sensitive to. The vehicle vibrations transmitted through the adapter during ascent tend to be of lower frequency than the shock typically imparted by the sep system (usually Marman ring) banging open. But either can be damaging to a satellite depending on its natural frequencies, so it all depends.

I'd guess Zuma may have had some super-sensitive instruments that couldn't be sufficiently decoupled from the vibe/shock loads of ascent or separation, so they had to design the damping into the adapter.

I'd also guess the damping required some unusual low-shock (ie non-Marman-ring)  separation mechanism, which makes trying to use a SpaceX adapter pointless, because you have to redesign the important part of it anyway, so you may as well start from scratch.
« Last Edit: 04/09/2018 11:01 pm by Kabloona »

Offline Kabloona

  • Senior Member
  • *****
  • Posts: 4846
  • Velocitas Eradico
  • Fortress of Solitude
  • Liked: 3429
  • Likes Given: 741
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1698 on: 04/09/2018 10:49 pm »
How often do payload adapters fail? Is doesn't seem like a common failure.

Adapters themselves virtually never fail, because they're dumb structures that are easy to design and manufacture. The separation system attached to the adapter, however, is a not-uncommon failure point.

The standard Marman ring sep system is pretty fool-proof, but when people try re-inventing the wheel (apparently what NG did in this case) without adequate testing, that's when failures get much more likely.

Here's an excellent summary article on payload separation failures, written shortly after the Zuma failure:

http://www.thespacereview.com/article/3439/1
« Last Edit: 04/09/2018 11:23 pm by Kabloona »

Offline Star One

  • Senior Member
  • *****
  • Posts: 13997
  • UK
  • Liked: 3974
  • Likes Given: 220
Re: SpaceX F9 : Zuma : January 7/8, 2018, CCAFS : DISCUSSION
« Reply #1699 on: 04/09/2018 11:00 pm »
Will the government be looking to claw back any of the $3.5 billion of taxpayers money from NG if in the final analysis it is categorically their fault for the payload loss?

Or as will more likely will happen the federal government will give them another $3.5 billion to build a replacement if its mission was high priority.
« Last Edit: 04/09/2018 11:06 pm by Star One »

Tags:
 

Advertisement NovaTech
Advertisement Northrop Grumman
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
1