Author Topic: SpaceX Falcon 9 v1.1 - SpX-7/CRS-7 DRAGON - Discussion Thread 1  (Read 994976 times)

Offline Jarnis

  • Full Member
  • ****
  • Posts: 1311
  • Liked: 827
  • Likes Given: 199
Not saying this is the cause but the trunk always looked fragile to me... maybe i've played kerbal too much but i believe some struts would be needed. in the middle and/or at the end.
This flight it has to support the IDA that weights 500kg and then you have the fully loaded Dragon, and 9 merlins pushing below..
I don't think the trunk has been loaded this much on earlier flights.
So, structual failing of the trunk, not because of the IDA coming loose but because of excessive load?

Unlikely. This would require so basic level fail at load analysis math that I cannot see it happening. Also there are margins built in for a reason.

Everything so far publicly shared (pretty much the visual evidence in the video and the fact that SpaceX hasn't immediately found and publicized a reason) still points to "something" increasing the pressure of the LOX tank to a point where it burst a hole, spilled the contents and then things went downhill from there *or* LOX tank somehow failing under normal ascent loads, spilling the contents etc.

Figuring out what that "something" or figuring what and why gave up in the LOX tank is and doing it conclusively probably will take a while.

Offline hrissan

  • Full Member
  • ****
  • Posts: 411
  • Novosibirsk, Russia
  • Liked: 325
  • Likes Given: 2432
My turn to present an idea.

What if the COPV mounting bracket failed during max-vibration and it became loose? Sooner or later the He line fitting would break launching "In-tank COPV rocket" which will accelerate and ram into LOX tank dome, then start kicking the tank walls flying around until all helium is lost.

If it hit the manhole it could propel the manhole cover right into avionics package destroying telemetry in milliseconds after the pressure event from broken He line is registered by sensors.

Or if it hit the weld between the dome and tank wall it could rip it open, gushing LOX into avionics package destroying telemetry a bit slower then direct-hit scenario.

In both scenarios after the tank ullage pressure is lost the tank collapses until dome touches LOX surface, then the slow "squeezing LOX out" commences, and the more LOX is squeezed out, the more tank buckling progresses with wider and more holes for LOX to escape until total failure, then the same happens with RP tank.

Offline edkyle99

  • Expert
  • Senior Member
  • *****
  • Posts: 15349
    • Space Launch Report
  • Liked: 8487
  • Likes Given: 1345

Offline kevinof

  • Full Member
  • ****
  • Posts: 1594
  • Somewhere on the boat
  • Liked: 1869
  • Likes Given: 1262
Not saying this is the cause but the trunk always looked fragile to me... maybe i've played kerbal too much but i believe some struts would be needed. in the middle and/or at the end.
This flight it has to support the IDA that weights 500kg and then you have the fully loaded Dragon, and 9 merlins pushing below..
I don't think the trunk has been loaded this much on earlier flights.
So, structual failing of the trunk, not because of the IDA coming loose but because of excessive load?

I can't see that as the cause. Getting the structure strength right on the trunk is a basic engineering task and not something I can see SpaceX getting wrong. They have shown time and again that they are very good engineers and something as basic as this would just not happen.

« Last Edit: 07/01/2015 02:14 pm by kevinof »

Offline Kim Keller

  • Full Member
  • ****
  • Posts: 970
  • Not OldSpace, Not NewSpace - I'm ALLSpace
  • Location: Wherever the rockets are
  • Liked: 2419
  • Likes Given: 125
Trying to put this one to bed:

Ground initiated FTS was triggered, but occurred far too late to have any effect -- 70 seconds after "the incident" (however you define that).  It was triggered (manually, by a person) to hopefully detonate any ordinance that survived the breakup, so that it would not be hazardous to those combing the debris field.

The breakwire FTS is automatic, on the vehicle.  It seems likely that it did *not* activate: the first FTS action is engine shutdown, and the stage 1 engines were seen firing until breakup was well under way.  This is not entirely clear, perhaps your opinion may differ.  However, we have confirmed that FTS activation *would* be included in the S1 telemetry.  So if the automatic S1 breakwire FTS was invoked, SpaceX know about it.

Finally, to everyone who will (zombie-like) arise to say that S1 FTS should be independent of S2 FTS -- they *are*.  Already.  SpaceX did this specifically because of S1 recovery.  But that applies only after separation, and the stages have not yet separated.

A few clarifying notes:

The destruct command was sent solely to reset the MFCO's console, which was in a "rocket amber" state, one step away from "rocket red" which would have ordered destruct. There was nothing - let me repeat that, nothing - left that could receive the command and initiate unexploded ordnance. Nothing.

Second, the breakwires would be between S2 and the Dragon. There is no need for breakwires between S1 & S2 due to the presence of an FTS system on each stage.
« Last Edit: 07/01/2015 02:02 pm by Kim Keller »

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 37429
  • Cape Canaveral Spaceport
  • Liked: 21434
  • Likes Given: 428
Makes no sense to put a heating element in the COPV.
Its inside a Lox tank you don't want the contamination.

Usually if the he is to be heated it would be external, ie like a bass around the engine, or around the turbo pump pre-burner or TP exhaust,  or even a coil in the RP-1, but not in the bottle... the whole point of putting the bottles in the LOX is to keep them cold. The he in the COPV is a gas, no need to stir like a liquid that would stratify... and the Lox is warm enough that the he  no where near the point it would condense.

No need for any heating elements what so ever

Offline MarekCyzio

My primary issue with COPV failure is as follows...

The 2nd stage vented LOX slowly over a period of a second or more.
This visually  looks like a hydraulic failure not a gas pressure fed failure.


What if gas pressure casued top of the oxygen tank to blew off? That would be consistent with Dragon + trunk separating early and would not cause massive LOX leak. Just asking...
« Last Edit: 07/01/2015 01:36 pm by MarekCyzio »

Offline meekGee

  • Senior Member
  • *****
  • Posts: 14123
  • N. California
  • Liked: 13996
  • Likes Given: 1390
Not saying this is the cause but the trunk always looked fragile to me... maybe i've played kerbal too much but i believe some struts would be needed. in the middle and/or at the end.
This flight it has to support the IDA that weights 500kg and then you have the fully loaded Dragon, and 9 merlins pushing below..
I don't think the trunk has been loaded this much on earlier flights.
So, structual failing of the trunk, not because of the IDA coming loose but because of excessive load?

Unlikely. This would require so basic level fail at load analysis math that I cannot see it happening. Also there are margins built in for a reason.

Everything so far publicly shared (pretty much the visual evidence in the video and the fact that SpaceX hasn't immediately found and publicized a reason) still points to "something" increasing the pressure of the LOX tank to a point where it burst a hole, spilled the contents and then things went downhill from there *or* LOX tank somehow failing under normal ascent loads, spilling the contents etc.

Figuring out what that "something" or figuring what and why gave up in the LOX tank is and doing it conclusively probably will take a while.

There was a failing somewhere, and I'd bet on a manufacturing issue before I go for a basic design flaw.

Just like a COPV can fail even though it was analyzed to death, or the outer jacket of the cooling manifold on an M1C can.  Happened to SpaceX, and happened to others.

On any particular flight, the less margin you have, the more likely it is that a manufacturing defect would manifest itself.

So if a hypothetical flaw existed in the trunk, then the loading of the trunk is significant.

It can be a local failure right near the attach points, but no doubt the structure is beefed up around the attach points, so the defect/failure are equally likely anywhere within the trunk.

If you want to go by "What's different about this flight" (which is a conditional probability argument) then you'd consider that A) parts of the trunk are loaded differently because of the payload arrangement, and B) some parts, such as the adapter between the payload and the trunk, are actually completely new.

« Last Edit: 07/01/2015 02:03 pm by meekGee »
ABCD - Always Be Counting Down

Offline Remes

  • Full Member
  • ****
  • Posts: 428
  • Germany
  • Liked: 243
  • Likes Given: 142
'Frames' are not really relevant here.  No need to accumulate data to build a frame before transmitting. The 'frame' is just the programmable multiplexor definition for some fixed period.  The 'frame' is marked by programming the multiplexor to output fixed 'sync' words at the beginning (or end) of the period. 
If you add error correction, and I don't know any digital system transmitting data which don't, then you do have to partition your data in chunks, calculate the error correction, and send data + data for error correction. Calculating the ECC-data takes some time, therefore the data frame must be stored. The receiver side must use the same chunks of data to execute error checking and correction if necessary and possible.

And another thought: the data might be encrypted, encryption and authentication doesn't work on the fly (not impossible, but takes a lot of ressources. Encryption might prevent competitors or space enthusiasts to listen to all flight parameters. Authentication might be required: Just imagine someone messes with the data and an abort decision is made on invalid telemetry.

One might imagine that the pressurization regulation valves are in triple double strings so with triple redundant flight computers any two computers can turn on a valve. (active bang bang vales will be lighter that a dome loaded regulator of the required size, also hard to set up redundancy with DL Reg.)
The few systems I saw tend to have rather 2 or three coils on each solenoid valve. The windings beeing driven by different computers, remote boxes. One system had 2 strings of valves, each with multiple coils.
« Last Edit: 07/01/2015 02:55 pm by Remes »

Offline StuffOfInterest

  • Full Member
  • ****
  • Posts: 925
  • Just interested in space
  • McLean, Virginia, USA
  • Liked: 887
  • Likes Given: 226
If you add error correction, and I don't know any digital system transmitting data which don't, then you do have to partition your data in chunks, calculate the error correction, and send data + data for error correction. Calculating the ECC-data takes some time, therefore the data frame must be stored. The receiver side must use the same chunks of data to execute error checking and correction if necessary and possible.

And another thought: the data might be encrypted, encryption and authentication doesn't work on the fly (not impossible, but takes a lot of ressources. Encryption might prevent competitors or space enthusiasts to listen to all flight parameters. Authentication might be required: Just imagine someone messes with the data and an abort decision is made on invalid telemetry.

I doubt there is any encryption involved here.  For one thing, you would have to know the format of the incoming telemetry to make any sense of the frame received.  For another, the byte by byte analysis that SpaceX is doing on the final frame would be useless if there was encryption involved.  ECC on the other hand may be present.

Offline LouScheffer

  • Senior Member
  • *****
  • Posts: 3370
  • Liked: 6071
  • Likes Given: 828
'Frames' are not really relevant here.  No need to accumulate data to build a frame before transmitting. The 'frame' is just the programmable multiplexor definition for some fixed period.  The 'frame' is marked by programming the multiplexor to output fixed 'sync' words at the beginning (or end) of the period. 
If you add error correction, and I don't know any digital system transmitting data which don't, then you do have to partition your data in chunks, calculate the error correction, and send data + data for error correction. Calculating the ECC-data takes some time, therefore the data frame must be stored.
You don't need to wait for the whole frame to use error-correcting codes.  There are at least two ways that both use error correcting codes AND send data as it comes in - convolutional codes or systematic codes.

A systematic code is one where the raw bits are part of the packet.  ( https://en.wikipedia.org/wiki/Systematic_code ).  So you send the raw bits, calculating the error correction bits as you go, then send the error correction bits at the end.  At the rates of telemetry discussed here, there will be no problem computing the correction bits as the data goes out.

Alternatively, you can use a convolutional code, ( https://en.wikipedia.org/wiki/Convolutional_code ), often used in deep space communication.  Here the error correction data is computed over the last few bits (not the whole frame).  Extremely fast and easy to implement in hardware, but more work to decode (needs a Viterbi decoder for best results).

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 37429
  • Cape Canaveral Spaceport
  • Liked: 21434
  • Likes Given: 428

As I brought up earlier in this thread Chris about harmonics/resonance of the stack, no where have I see that SpaceX does these types of ground tests as is done by NASA in Huntsville. I recall vibration testing during Apollo and Shuttle years. Have you ever seen evidence of such testing? I would hope/assume such testing has been done other than computer sims...

Not really needed.  It is done by structural subassembly.
« Last Edit: 07/01/2015 02:51 pm by Jim »

Offline Prober

  • Senior Member
  • *****
  • Posts: 10348
  • Save the spin....I'm keeping you honest!
  • Nevada
  • Liked: 721
  • Likes Given: 729
Coast Guard Crew Assists in SpaceX Debris Recovery

Published on Jun 30, 2015
An HC-130 Hercules aircrew from Coast Guard Air Station Clearwater, Florida, drops flares to mark debris near Port Canaveral, Florida, Sunday, June 28, 2015. The crew assisted NASA vessels in debris recovery after a SpaceX rocket exploded minutes after launching.

U.S. Coast Guard video by Chief Petty Officer Crystalynn A. Kneen



interesting question: who pays for the use of NASA services and the US Coast Guard?   

Just wondering if its defined in the contract.  See, you could make the point SpaceX should be contracting for the services since this is a contracted launch.   

On the other hand; some valuable NASA assets were lost and any recovery might lesson that loss.

So who pays?


2017 - Everything Old is New Again.
"I fear all we have done is to awaken a sleeping giant..." --Isoroku Yamamoto

Offline Kabloona

  • Senior Member
  • *****
  • Posts: 4846
  • Velocitas Eradico
  • Fortress of Solitude
  • Liked: 3429
  • Likes Given: 741
Coast Guard typically does not charge for search and rescue.

Offline R7

  • Propulsophile
  • Senior Member
  • *****
  • Posts: 2725
    • Don't worry.. we can still be fans of OSC and SNC
  • Liked: 992
  • Likes Given: 668
Not saying this is the cause but the trunk always looked fragile to me... maybe i've played kerbal too much but i believe some struts would be needed. in the middle and/or at the end.

Yet an interstage without such struts manages to keep ~100t S2 and payload attached to ~400t S1 just fine.
AD·ASTRA·ASTRORVM·GRATIA

Offline Doesitfloat

  • Full Member
  • ***
  • Posts: 332
  • Detroit MI
  • Liked: 498
  • Likes Given: 197
Coast Guard Crew Assists in SpaceX Debris Recovery

Published on Jun 30, 2015
An HC-130 Hercules aircrew from Coast Guard Air Station Clearwater, Florida, drops flares to mark debris near Port Canaveral, Florida, Sunday, June 28, 2015. The crew assisted NASA vessels in debris recovery after a SpaceX rocket exploded minutes after launching.


interesting question: who pays for the use of NASA services and the US Coast Guard?   

Just wondering if its defined in the contract.  See, you could make the point SpaceX should be contracting for the services since this is a contracted launch.   

On the other hand; some valuable NASA assets were lost and any recovery might lesson that loss.

So who pays?

The Federal Government funds the Coast Guard. It is the Coast Guard's policy not to charge the victims or people in distress. My understanding is the if they did charge; it could lead to people not calling for help when they need it.
Edit: Formatting
« Last Edit: 07/01/2015 03:32 pm by Doesitfloat »

Offline edkyle99

  • Expert
  • Senior Member
  • *****
  • Posts: 15349
    • Space Launch Report
  • Liked: 8487
  • Likes Given: 1345
Trying to put this one to bed:

Ground initiated FTS was triggered, but occurred far too late to have any effect -- 70 seconds after "the incident" (however you define that).  It was triggered (manually, by a person) to hopefully detonate any ordinance that survived the breakup, so that it would not be hazardous to those combing the debris field.

The breakwire FTS is automatic, on the vehicle.  It seems likely that it did *not* activate: the first FTS action is engine shutdown, and the stage 1 engines were seen firing until breakup was well under way.  This is not entirely clear, perhaps your opinion may differ.  However, we have confirmed that FTS activation *would* be included in the S1 telemetry.  So if the automatic S1 breakwire FTS was invoked, SpaceX know about it.

Finally, to everyone who will (zombie-like) arise to say that S1 FTS should be independent of S2 FTS -- they *are*.  Already.  SpaceX did this specifically because of S1 recovery.  But that applies only after separation, and the stages have not yet separated.

A few clarifying notes:

The destruct command was sent solely to reset the MFCO's console, which was in a "rocket amber" state, one step away from "rocket red" which would have ordered destruct. There was nothing - let me repeat that, nothing - left that could receive the command and initiate unexploded ordnance. Nothing.

Second, the breakwires would be between S2 and the Dragon. There is no need for breakwires between S1 & S2 due to the presence of an FTS system on each stage.
So the fact that FTS was not triggered is a potentially useful clue?

 - Ed Kyle

Offline clegg78

  • I play KSP, so I know things about rockets and stuff... :)
  • Full Member
  • *
  • Posts: 121
  • Denver, CO
  • Liked: 92
  • Likes Given: 15
Yep same thing with the Air Force SAR resources, all tax payer funded.
Buy the Ticket, Take the Ride - Hunter S Thompson

Offline jimvela

  • Member
  • Full Member
  • ****
  • Posts: 1656
  • Liked: 889
  • Likes Given: 69
Since we're talking about telemetry, I'll throw a bit of my knowledge into the ring.

I build systems that process ground and flight telemetry for spacecraft and instrument avionics (not launch vehicles).

I know nothing about SpaceX' implementation, so I won't even try to give anything specific about their vehicles.

Also, some of what I describe below for spacecraft doesn't apply to launch vehicles as there isn't any time to send commands to a launch vehicle as the launch sequence is highly dynamic and relies heavily on pre-programmed event sequences.  As far as I know, there are no commands sent to a launch vehicle during launch after liftoff, aside from an FTS destruct command.

There are standards at work for telemetry, e.g. CCSDS.  There are also as many different implementations of the 'standard' as there are manufacturers of avionics.

In  everything I work on, flight software does in fact format telemetry, packaging frames inside of headers.  There are multiple layers of framing at work, and there can be many different types of telemetry frames coming down at various rates. 

Some things happen on a deterministic schedule, some telemetry can be inserted out-of-order if the priority of the data is high enough, and some things may only come down if there is available bandwidth to send it without disrupting the flow of high-priority telemetry.

Depending on the operating modes of the avionics, there can be many different rates and maps.  For example, if a spacecraft has entered safe mode (or if an emergency mode controller has taken over the operation of a spacecraft), the data rate and telemetry map can switch to fairly low bit rates (better for retrieving data on the ground if there is a pointing or power problem with the transmitters), and the maps can prioritize only critical engineering telemetry.

Many avionics systems can and do acquire data more rapidly than they send telemetry, in which case the telemetry maps define how often and what kinds of data to send.  It is not unusual to have instrumentation for developmental hardware sending telemetry and higher than normal rates. 

Likewise, any anomalous condition will often times be prioritized to send that status back as a high-priority telemetry frame.

On all the flight avionics that I work on, there are multiple boxes intercommunicating to flow data that ends up send down in telemetry.  A high-energy event can (and indeed is very likely to) cause telemetry to stop being transmitted even if the avionics and flight software are continuing to acquire data.

Unlike launch vehicles, the rates and maps on most spacecraft can be commanded as well as switched autonomously by flight software.

Almost everything I work on is capable of sending unencrypted telemetry, however in flight use everything I deal with defaults to using encryption.  Aside from encryption, there can be randomization also applied.

There are no analog telemetry signals on anything I work on, and as far as I know, modern launch vehicles to not transmit any analog telemetry- it's all digitally encoded, framed, and transmitted by flight software within the avionics.

The other Jim above mentioned that this type of event could spell the end of store-and-forward telemetry, and I have my own take on this.  I don't believe that it is appropriate to *ONLY* log telemetry on a launch vehicle, and that engineering telemetry during the early phases of launch should be transmitted live.

I do see the value of a rugged data logger which is essentially digital storage packaged as robustly as it can be, with the intent of building a package that can survive a mishap and be recovered.  This is a very difficult challenge on a launch vehicle as they operate right on the edge of having sufficient margin to even survive as the physics of launch are very challenging. 

In the scenario above where a high-energy event kills the communication between avionics, a high-rate log might be able to provide some critical insight into sensor data in a mishap, were it to be recovered.

I to expect, however, with the proliferation of sensors generating engineering and operational telemetry that there will be some lower-priority data which will always be stored and made available for downlink if conditions permit.

It is always better to get all critical sensor data down in near real time than count on retrieval after a mishap.  Picking what sensors are critical is a challenging activity.  In the words of Mr. Musk, some failures can be counter intuitive and a sensor that you thought wasn't critical can, in retrospect, be the most critical sensor needed to decipher an event chain that leads to catastrophic failure of the vehicle.

Offline Rocket Science

  • Senior Member
  • *****
  • Posts: 10586
  • NASA Educator Astronaut Candidate Applicant 2002
  • Liked: 4548
  • Likes Given: 13523

As I brought up earlier in this thread Chris about harmonics/resonance of the stack, no where have I see that SpaceX does these types of ground tests as is done by NASA in Huntsville. I recall vibration testing during Apollo and Shuttle years. Have you ever seen evidence of such testing? I would hope/assume such testing has been done other than computer sims...

Not really needed.  It is done by structural subassembly.
Reading you correctly, these tests linked below are no longer done?
http://www.nasa.gov/centers/marshall/multimedia/photos/2008/photos08-040.html
"The laws of physics are unforgiving"
~Rob: Physics instructor, Aviator

Tags:
 

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