STS51L Accident Questions

On 08 Mar 2005 05:35:29 GMT, "Jorge R. Frank"
wrote:

Scott Lowther is handling this the right way. Watch, and learn.

....The only proof that this method works is if a) all the M*****s
disappear, and b) the current troll concedes defeat first.

[Breath_hold_mode=Off(eternal)]

OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

wrote:

Herb Schaltegger wrote:

Given Scott's current job and his experience with solid rockets
generally, his comments are very interesting. I further appreciate
his willingness to suspend any urge towards editorializing to discuss

the information actually available rather than shooting the
messenger.

In this case, the primary issue under discussion... the matter of
sample rates and the determination thereof... really is a
straightforward matter of numbers and knownign generally how the system
works. There is no real area for debate... the data is what it is, and
it appears fully consistent with what it's *supposed* to be.

Please explain the variable data rate. I don't think I am asking too much
in making that request.

Now, as for what happens with the data around 59 seconds, when the two
SRB's begin to diverge, THAT would be an area where interpretation and
debate can come in.

Sure. I agree there especially given the earlier divergences between the
two boosters.

Daniel

OMG. I hope you didn't really mean what you wrote. "...sometime (sic)
you have to gamble."????? NO WAY. Launching Challenger AGAINST
PROTOCOL, with icicles hanging off of it, was irresponsible at BEST,
and I hope the FOOL who gave the final "Go" has never slept a wink
since. I don't care if Reagan had to fly down to the Cape FIVE DOZEN
TIMES...you do NOT risk the crew!!!!! PERIOD.
Space flight is inherently dangerous, so "gambling" on KNOWN hazards is
tantamount to murder.

wrote:

The Shuttle flight data is not what you might hope for. It was
restricted in its capabilities by 1970's computer capabilities, and it
just never got updated. This is partially due to inertia (getting the
new, far higher sample rate xducers approved is a rather time- and
taxpayer-dollar-consuming enterprise), and partially due to the fact
for a motor that runs for 2 minutes, 12.5 samples per second is
adequate for post-flight reconstruction. As mentioned before, it's not
really what you want for brief events, blips and initiation; but in 220
or so flights, there has never been an issue with any of the motors
except for Challenger...

They did have that problem with aluminum slag expulsion causing spikes in
the chamber pressure at around T+ 80 sceonds or so and the pc sensors were
sensitive enough to pick that issue up. To NASA's credit they figured it
out. Ironically the problem was actually discovered pre STS 1, IIRC, and
subsequently forgotten apparently. I think that issue was found in the STS
54 timeframe, again IIRC. I believe it would have been missed if NASA had
not upgraded the status/control of the pc measurements following STS 51-L.

and that was hardly a ballistics problem. You
can not reasonably expect a motor to have a perfectly normal pressure
trace if you open a second port in the side...

No but the data rate should not change because of such a leak.

The problem with interprettign the given Challenger data is due to some
goofy but explainable phenomena. For starters... the xducers *are* 25
samples per second, but only every other one is read, leading to 12.5
sps. Then there's the fact that there are two other, slower xducers...
and 5 does not go into 12.5, so you have to decide how you're going to
present these different data streams.

I agree that the solution was not perfect, but if you look at all of the
data, you will see that there are problems of data rate consistency
throughout the flight and other problems too. In a perfect world, NASA
would have separated all of the telemetry they sent to me into its
respective data streams as they were downlisted with the correct METs. If
this was the only data set I had to look at, I would not be discussing it at
all. There are others and we will get to them if there is interest and
people like you continue to add to the discussion.

The data given here presents them
all with a single time axis; the way we get the data from static tests
(again, haven't been here long enough for a flight...) is that each
xducer has it's own time *and* pressure column. So when we have xducers
of different rates, it can be difficult to work with. If you just want
to plot them together, that's easy, leav ethe data alone, they'll plot
just fine. But if you want to compare moment-by-moment performance, you
need to pick a sample rate, and then interpolate the others to fit that
data rate. This works, but it's not the data you were originally given,
and you have to be careful with that.

Thanks.

What was done with the Challenger data is not what we'd do today. What
they did Way Back Then was, it seems, to include every time point
recorded from all three xducer streams. That's good for plotting, but
it gives you some weird variability in percieved data rate. And then,
instead of interpolating between pressure data points, they simply
repeated the data between relevant time points. An odd way of going
about it, but an honest one, and one that can be easily interpretted if
you know how... and easily *mis*interpretted if you don't know how.

Please take a look at all of the data.

Daniel
Mount Charleston, not Charleston SC

wrote:

A revision after discussion with co-workers: the SRM pressure
transducers *do* pick up data at 25 sps. But the data aquisition system
on the shuttle *alternates* grabbing data. So, each Xducer loses every
other data point, and the *effective* data rate is thus 12.5/sec.

So how then was it "grabbing" 25 samples per second in the case of STS 51-L
and 51-L alone? Was my statement as far as actual data acquisition
therefore correct--12.5 samples into the data stream/downlink? Not that the
25 s/s rate holds up throughout this particular data set.

Daniel
Mount Charleston, not Chrleston SC

OM om@our_blessed_lady_mary_of_the_holy_NASA_researc h_facility.org wrote
in :

On 08 Mar 2005 05:35:29 GMT, "Jorge R. Frank"
wrote:

Scott Lowther is handling this the right way. Watch, and learn.

...The only proof that this method works is if a) all the M*****s
disappear, and b) the current troll concedes defeat first.

[Breath_hold_mode=Off(eternal)]

I'll settle for a lack of trollish behavior, whether it's due to trolls
leaving, or simply deciding not to act like trolls any more.

I'm not holding my breath either, but Scott's method can't possibly turn
out any worse than what hasn't worked the last four years, so it's worth a
shot.

--
JRF

Reply-to address spam-proofed - to reply by E-mail,
check "Organization" (I am not assimilated) and
think one step ahead of IBM.

In article ,
"Jorge R. Frank" wrote:

I'm not holding my breath either, but Scott's method can't possibly turn
out any worse than what hasn't worked the last four years, so it's worth a
shot.

Besides which, the current thread is at least on-topic (although it's
just as on-topic for s.s.s) and it is interesting and informative.
Let's just see where it leads.

If I had a few days off I'd love to delve into Daniel's spreadsheet
data further. While I don't have Scott's experience with solid
rockets, I do have experiencing spec'ing and procuring pressure
transducers that interface with digital data systems. I am further
interested in seeing a comparison with data from some of those other
missions Daniel has. I'd like to see the contrasts (if any).

--
Herb Schaltegger, B.S., J.D., GPG Key ID: BBF6FC1C
"The loss of the American system of checks and balances is more of a security
danger than any terrorist risk." -- Bruce Schneier
http://dischordia.blogspot.com
http://www.angryherb.net

Charleston wrote:
wrote:

A revision after discussion with co-workers: the SRM pressure
transducers *do* pick up data at 25 sps. But the data aquisition
system
on the shuttle *alternates* grabbing data. So, each Xducer loses
every
other data point, and the *effective* data rate is thus 12.5/sec.

So how then was it "grabbing" 25 samples per second in the case of
STS 51-L
and 51-L alone?

It does that every flight, not just 51-L.

They did have that problem with aluminum slag expulsion causing
spikes in
the chamber pressure at around T+ 80 sceonds or so and the pc sensors
were
sensitive enough to pick that issue up.

Slag is a constant issue. 12.5 sps is enough to pick it up and
recognize it, but you'd want faster data rates for better
characterization AND for dealing with unknown types of pressure blips.

the data rate should not change because of such a leak

I see no evidence of a change in data rate.

I tried replying earlier, and Netscape crashed just as I hit the "send"
button. Bah. So here's a truncated reply.

My review of the data as posted at the above URL, led directly to a
subsequent phone call to the above engineer and an admission by him
that for
the timeframe T+0 to T+1 second, no "real" data was available for STS
51-L
and therefore "theoretical trajectory based data was substituted
instead".

I can't comment on what you say someone else said.

Okay we disagree on whether the second one is 2 or 5 s/s. Is there
any
particular reason you believe the second one is five?

Transducer 1300 begins a new data set ever 0.2 seconds. That's 5 times
per second.

Can you explain the variable data rate?

What variable data rate? You mean the 1, 5 and 12.5 sps? That was a
decision that was made when I was still in grade school.

Please graph the above two sets of data I have added to my website
for that
first second on the same graph and let me know if you still think your
explanation works.

I did so. Focussing just on the 1302 and 2302 xducers ar 12.5 sps, when
you take the two "different" data sets and put them together and use
the Excel sort command to get everythign in chronological order, you
get:

Left SRB Right SRB
B47P1302C B472302C
0.000 13.911 14.371
0.013 13.911 14.371
0.053 13.911 14.371
0.093 13.911 38.24
0.133 45.405 38.24
0.173 45.405 89.957
0.213 346.575 89.957
0.253 346.575 491.758
0.293 620.186 491.758
0.333 620.186 716.527
0.373 777.66 716.527
0.413 777.66 825.928
0.453 852.46 825.928
0.493 852.46 879.635
0.533 887.892 879.635
0.573 887.892 903.504
0.613 903.639 903.504
0.653 903.639 911.46
0.693 907.576 911.46
0.733 907.576 911.46
0.773 905.607 911.46
0.813 905.607 909.471
0.853 903.639 909.471
0.893 903.639 907.482
0.933 903.639 907.482
0.973 903.639 905.493


Note that each data set retains the paired data, as before.

Which set of data points would you have me take out?

That's easy. In the new Excel chart you posted, for the 12.5 sps data
take out columns V and I. It's plain to see that V and I are the same
data as H and W... but come one time step later. The reason for the
flip-flop (and not, say, just takign out H and I) is because the DAS is
looking first at one xducer, then the other, not both at the same time.

In the grand scheme of things, you can probably take out H and W if you
want; you'll have the same data, just offset in time by a few dozen
milliseconds.

tell you what, you can call it "unlikely" if you
want to, but you can always read the CEI document I was referring to
for
yourself.

The CEI is the wrong place to look for calibration requirements for the
xducers. Look for the specs for the xducer vendors. That's not the
motor CEI's job.

You can not get that first second of data.

Sure you can. Just read a few lines up, it's right there.

Nominally? Show me the data.

I have no idea whether I can post Shuttle data and not get fired. I
can, however, tell you that the data is in line with a nominal motor
firing.

All I ask of you or anyone here is that before you comment to the
facts,
that you give at least one serious examination of all the data I have
provided.

I have done so. You have pointed out an oddity in the data, in the form
of the repeated data, and I have pointed out where that oddity comes
from and why it's there.