Quote from: rpapo on 04/09/2018 12:36 pmQuote from: jjyach on 04/09/2018 11:32 amThere 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.
Quote from: jjyach on 04/09/2018 11:32 amThere 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.
There is no way to delay reentry. It flies a preprogramed course flight profile regardless of what they may see.
Jeff Foust@jeff_foustWonder 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?
Google found this non-paywalled copy of above quote here
Quote from: jjyach on 04/09/2018 11:32 amThere 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?
Quote from: woods170 on 04/09/2018 08:57 amBasic 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 ZumaThanks 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.
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
Quote from: CorvusCorax on 04/09/2018 07:07 amGoogle found this non-paywalled copy of above quote hereNothing there except a search box?
Quote from: speedevil on 04/09/2018 07:55 pmHaving 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.
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?
Quote from: DistantTemple on 04/09/2018 11:47 amHowever 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.
However this scenario is an argument for having the ability to interrupt/override/update program, before deorbit begins.
Quote from: ugordan on 04/09/2018 12:17 pmQuote from: DistantTemple on 04/09/2018 11:47 amHowever 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?
Quote from: Norm38 on 04/09/2018 09:33 pmQuote from: ugordan on 04/09/2018 12:17 pmQuote from: DistantTemple on 04/09/2018 11:47 amHowever 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.
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"?
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.
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.
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.
How often do payload adapters fail? Is doesn't seem like a common failure.