LIVE: SpaceX - Falcon I (Mk.II) NET March 20 (Attempt 2)

[Chris Bergin]

http://www.spacex.com/updates.php

"Posted March 20, 2007

The abort that occurred a few minutes before T-0 was triggered by our ground control software. It commanded a switchover of range telemetry from landline to radio, which took place correctly, however, because of the hardware involved, this transition takes a few hundred milliseconds. Before it had time to complete, our system verification software examined state and aborted.

Our simulations done beforehand all passed, because the simulator did not account for a hardware driven delay in the transition. We considered putting the vehicle into a safe state yesterday and updating the ground control software to make the very minor fix needed, but the safer course of action was to stand down.

Yesterday afternoon and evening (Kwaj time), our launch team updated the software to address the timing issue and verified that there were no similar problems elsewhere. We ran the software through several simulated countdowns and then once again with the rocket and range in the loop.

All systems are now go for launch with T-0 at 4pm California time today (Tues)."

NOTE TO ALL:

During the countdown, please keep these pages clean. It's best to avoid multiple "I don't have audio, why?" and "My dog woofed GO SPACEX" etc.

So, only post if it's relevant, new and interesting.

[Jim]

Don't understand the transition time of the TM.  Most LV's do it at T-0.  There is some weird here

[Satori]

Chris Bergin - 20/3/2007  11:21 AM

(...)

NOTE TO ALL:

During the countdown, please keep these pages clean. It's best to avoid multiple "I don't have audio, why?" and "My dog woofed GO SPACEX" etc.

So, only post if it's relevant, new and interesting.

Hi!

I think it's better to clarify who are members that should post on the last five minutes to avoid those and other posts, or else we are going to see the same as yesterday.

[BarryKirk]

Well, sounds like making that transition time at T-120 or so is a good idea.  It would have been much worse to try to abort at T-00 seconds.  The turnaround time would have been much longer.

[aero313]

Our simulations done beforehand all passed, because the simulator did not account for a hardware driven delay in the transition.

This is an issue for LOTS of events during the ascent.  If they didn't get it right here, it doesn't bode well for the powered flight phase.

[Jim]

BarryKirk - 20/3/2007  12:45 PM

Well, sounds like making that transition time at T-120 or so is a good idea.  It would have been much worse to try to abort at T-00 seconds.  The turnaround time would have been much longer.

It shouldn't be an issue.  There is no "transition" on the vehicle (or shouldn't be).  It is as simple as turning a switch from gound to flight data

[Chris Bergin]

Satori - 20/3/2007  4:42 PM

Chris Bergin - 20/3/2007  11:21 AM

(...)

NOTE TO ALL:

During the countdown, please keep these pages clean. It's best to avoid multiple "I don't have audio, why?" and "My dog woofed GO SPACEX" etc.

So, only post if it's relevant, new and interesting.

Hi!

I think it's better to clarify who are members that should post on the last five minutes to avoid those and other posts, or else we are going to see the same as yesterday.

Yeah, I'll see what I can arrange.

I think rule one is during the countdown, we only want:

[kevin-rf]

aero313 - 20/3/2007  12:08 PM

Our simulations done beforehand all passed, because the simulator did not account for a hardware driven delay in the transition.

This is an issue for LOTS of events during the ascent.  If they didn't get it right here, it doesn't bode well for the powered flight phase.

Come on, reality never diverges from simulations ;-) Based on the flag this raised I would be taking a close look at timing issues involved with the staging event.

I am now wondering if it was prudent to delay only 24hrs. Tweaking timeouts is something that should be fully reviewed before comitting to released code. Only 6 more hours until we find out.
 
A few years back didn't a Centuar upper stage fail to deliver its payload to the proper orbit because the wrong burn times where entered into the flight computer? Titan-IV, Milstar-2-1 me thinks...

[Lee Jay]

Chris Bergin - 20/3/2007  11:20 AM

Satori - 20/3/2007  4:42 PM

Chris Bergin - 20/3/2007  11:21 AM

(...)

NOTE TO ALL:

During the countdown, please keep these pages clean. It's best to avoid multiple "I don't have audio, why?" and "My dog woofed GO SPACEX" etc.

So, only post if it's relevant, new and interesting.

Hi!

I think it's better to clarify who are members that should post on the last five minutes to avoid those and other posts, or else we are going to see the same as yesterday.

Yeah, I'll see what I can arrange.

I think rule one is during the countdown, we only want:

Screaming lunatics?  I thought we had too many already.  In fact, that's why I tend to stay silent.  But okay...  ;-)

Lee Jay

[Chris Bergin]

20 percent chance of rain:

Updated: 4:55 AM MHT on March 21, 2007
Observed at:   Kwajalein, MH
Elevation:   26 ft / 8 m

   81 °F / 27 °C
Scattered Clouds
Humidity:   78%
Dew Point:   74 °F / 23 °C
Wind:   14 mph / 22 km/h / 6.2 m/s  from the NE  

Pressure:   29.83 in / 1010 hPa
Heat Index:   87 °F / 30 °C
Visibility:   10.0 miles / 16.1 kilometers
UV:   0 out of 16
Clouds:   Few 2300 ft / 701 m
Few 3500 ft / 1066 m
Scattered Clouds 35000 ft / 10668 m
Scattered Clouds 40000 ft / 12192 m
(Above Ground Level)
Chance of Rain
20% chance of precipitation

[NotGncDude]

aero313 - 20/3/2007  1:08 PM

Our simulations done beforehand all passed, because the simulator did not account for a hardware driven delay in the transition.

This is an issue for LOTS of events during the ascent.  If they didn't get it right here, it doesn't bode well for the powered flight phase.

No way. This has to be an issue with the ground control software only. It's impossible to write flight software without paying attention to these delays (Although you could argue the same about the ground software)

[ETEE]

Jim - 20/3/2007  6:14 PM

BarryKirk - 20/3/2007  12:45 PM

Well, sounds like making that transition time at T-120 or so is a good idea.  It would have been much worse to try to abort at T-00 seconds.  The turnaround time would have been much longer.

It shouldn't be an issue.  There is no "transition" on the vehicle (or shouldn't be).  It is as simple as turning a switch from gound to flight data

And presumably they will be 200mS late with their data due to the hardware delays already mentioned.

[aero313]

ianmga - 20/3/2007  2:00 PM

aero313 - 20/3/2007  1:08 PM

Our simulations done beforehand all passed, because the simulator did not account for a hardware driven delay in the transition.

This is an issue for LOTS of events during the ascent.  If they didn't get it right here, it doesn't bode well for the powered flight phase.

No way. This has to be an issue with the ground control software only. It's impossible to write flight software without paying attention to these delays (Although you could argue the same about the ground software)

Sorry, but I disagree.  There are lots of issues in flight where hardware latency can impact how software operates.   Valve opening or closing, ordnance function, TVC actuation, etc, etc.  If their simulations don't account for real hardware function times, there can be problems.  This is where real world experience and hardware in the loop testing trumps youth and enthusiasm.

Typical in a shakedown of new systems. Wise to take a day and look for related issues. Nice that its  a simple, obvious one. Bet whoever was responsible for the simulations had their ass chewed - one could have guessed such an issue might come up.

[NotGncDude]

Oh. I meant the opposite. I can see that they may have forgotten about the delays in the ground control software, perhaps in events where they were not an issue. However, in the flight software it is pretty basic to take into account all the hardware latency issues that you listed. I cannot believe that they did not include and simulate these correctly. I guess we'll soon find out.

[kevin-rf]

ianmga - 20/3/2007  2:00 PM

No way. This has to be an issue with the ground control software only. It's impossible to write flight software without paying attention to these delays (Although you could argue the same about the ground software)

Yeah, the first Delta III and Arianne 5 flights failures had nothing to do with improperly simulated flight parameters. Both where lost because the real world flight conditions diverged from the simulated conditions. Curse you mother nature ...

To its credit the Falcon I flight controls are a new design and on the first flight worked up until the point of the fire shutting down the main engine. The Delta III and Arianne 5 reused systems from earlier rockets.

Once the vehicle clears the pad the next period of multiple critical timings will be staging (Assuming the flight control system is properly modeled/damped). If it survives staging, I would wager we will get a dummy payload in orbit.  

If the Falcon I places a payload into a low inclination orbit and there are no satellite trackers on the equator to see it is it really in orbit :-)

Good luck guys...

[aero313]

kevin-rf - 20/3/2007  2:29 PM

Yeah, the first Delta III and Arianne 5 flights failures had nothing to do with improperly simulated flight parameters. Both where lost because the real world flight conditions diverged from the simulated conditions. Curse you mother nature ...

Not to mention Conestoga, the first Pegasus XL, the first HyperX...   Need I go on?

[imcub]

kevin-rf - 20/3/2007  10:27 AM

Come on, reality never diverges from simulations ;-) Based on the flag this raised I would be taking a close look at timing issues involved with the staging event.

I am now wondering if it was prudent to delay only 24hrs. Tweaking timeouts is something that should be fully reviewed before comitting to released code. Only 6 more hours until we find out.
 

Some of my old gray matter remembers that one of the delays on the first Columbia launch was a timing issue.  As I recall from the news stories, it seems that 2 of the 4 flight computers started up and were running on one side of a 40 kHz clock edge while the other 2 flight computers were started up and running on the other side.   End result ... a launch abort.  

In all the hundreds if not thousands of launch simulations, this problem had never been seen.

[WHAP]

kevin-rf - 20/3/2007  11:27 AM
A few years back didn't a Centuar upper stage fail to deliver its payload to the proper orbit because the wrong burn times where entered into the flight computer? Titan-IV, Milstar-2-1 me thinks...

Correct payload, but not because of a wrong burn time.  It WAS an incorrect parameter that one could argue should have been caught in a flight simulation, but for whatever reason either wasn't tested in the simulation or didn't have the effect that was actually seen in flight.

[Immersive]

Wanted to mention the level of automation in pad operations pre and during launch is pretty amazing for a civil outfit.  As I was watching yesterdays attempt, I saw how the pad "reacted" to the aborts (stongback trusse, helium and kersene vent pumps, etc.).

But I think that the team needs more loops though, interruptions left and right.