A Space & astronomy forum. SpaceBanter.com

Go Back   Home » SpaceBanter.com forum » Space Science » History
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

STS51L Accident Questions



 
 
Thread Tools Display Modes
  #71  
Old March 7th 05, 06:33 AM
Scott Lowther
external usenet poster
 
Posts: n/a
Default

Charleston wrote:

From your read of the data what is the data rate for xducers 1302 and
2302?


!2 samples per second.

How about the other two sets of xducers?


One and five samples per second. 1, 5 and 12 sps are what we run with to
this day. Likely to change sometime around STS 115 or after, though.



But to first order the overall pressure trace up until T+59 seconds looks
about right.



Following the redesign of the SRBs a higher thrust differential between the
two boosters was allowed. The data I posted reflects rather sensitive
instrumentation with three significant figures right? Given the resolution
of the xducers at 1/1000 of a PSI, what do you suppose the actual accuracy
is in PSI?

*Precision* may be down to milli-psi, but *accuracy* is another matter.
As a general rule of thumb on these, expect on the order of a percent
variability between smae make and model xducers in this application.
Vibration, heating and whatnot.




Neither the spread in readigns from Xducer to Xducer not the very jagged
appearance of the data are unusual.



Not back then, I must agree. Does that make it okay during steady state
burn?

Yup. 1,5, and 12 sps is more than adequate for post-flight ballistic
reconstruction. Kinda stinks for blips and ignition transient, so that's
why we're lookign at bumping it up by more than an order of magnitude.


Today I sort of doubt you have those spreads between the xducers.


Same data rates today. Our traces don;t have the jagged appearance
because int he data you've presented, the 3 xducers are displaying data
at all time points. To clean up the data, just delete the cells that
have the extraneous data (such as, say, B14-B16, B19-B21, C14-C25, etc.)


Quality high rate data is three things:

1. Expensive
2. Heavy
3. Processor intensive

Nevertheless, if one is going to stake a report on data like that to which I
have referred, it should be honestly presented, accurate within a tolerance
that makes the data truly relevant,

The data presented looks to be fully in compliance with what would have
been actually recorded. You can't present data that *wasn't* recorded.


Now one more thing, looking at the data, what interpretive value would you
place on it during the first second following T= 0?


I'm not sure what you're after. If you're askign if it looks right...
yes, it does. A spike followed by a dip in pressure follwed by a climb
back up. This is normal in *many* solid rockets: the igniter fires and
quickly pressurizes the case; the case begins to blow down, and then the
main propellant gets up to speed and drives the pressure back up.

If you delete the extraneous data, you'll see that the transducers
aren't grabbing data at the same time, but are offset by some
milliseconds. This also addes to the apparent lack of co-ordination
between them, as the pressure was constantly changing, and they weren;t
reading it at the same time.

  #72  
Old March 7th 05, 08:04 AM
Charleston
external usenet poster
 
Posts: n/a
Default

"Scott Lowther" wrote:
Charleston wrote:

From your read of the data what is the data rate for xducers 1302 and
2302?


!2 samples per second.


I know what the data rate was supposed to be and my question pertains to the
STS 51-L data I put on my website not data from post 51-L flights. NASA
repeatedly and throughout the five volumes of the Presidential Report,
stated that the data rate for those same xducers was 12.5 samples per
second. The cycle is completed every two seconds when the 25th sample is
finished. NASA reported the sample period as 80 milliseconds. That would
make sampling at a rate higher than 12.5 samples a bit difficult. If you
look at the first second of data again you will see that there are 25 data
points. That first second of data is farcical and NASA has since admitted
as much to me.

From the Executive Summary of the PC Report
http://history.nasa.gov/rogersrep/v1ch3.htm scroll down to pages 37-39 where
we have the following:

Channel Identifier Sample Rate Sample Period Description
(Samples/sec) (sec)
B47P1302C 12.5 0.080
LH SRM CHAMBER PRESSURE
B47P2302C 12.5 0.080
RH SRM CHAMBER PRESSURE

So again I ask what is your read of the data rate for the STS 51-L flight
data on my website?

How about the other two sets of xducers?

One and five samples per second. 1, 5 and 12 sps are what we run with to
this day. Likely to change sometime around STS 115 or after, though.


And back then on 51-L it was 1, 2, and 12.5 samples per second respectively.

*Precision* may be down to milli-psi, but *accuracy* is another matter. As
a general rule of thumb on these, expect on the order of a percent
variability between smae make and model xducers in this application.
Vibration, heating and whatnot.


Ah yes precision and accuracy, first year chemistry, thanks. Accuracy is
indeed another matter. I expect that NASA would have a standard and indeed
they did. The CEI requirement was +- 15 PSI but there was no requirement to
actually calibrate the pressure transducers. There was a requirement to
discard the transducers after three flights or so. I'd have to go look up
that number of flights to be sure. I think you would agree that if the
accuracy requirement was 15 PSI, that any interpretation of that data should
be caveated with an engineering disclaimer to that effect. No such
disclaimer exists anywhere that I have ever seen in any volume of the PC
Report. I find it quite nauseating that NASA suggested that their data was
quite accurate without ever addressing the issue of the accuracy
specification, nor lack of a calibration requirement. I guess it would be
embarrassing to admit that the measurements NASA relied on most were not in
fact reliable. It was like pulling teeth just to get the CEI document for
the HPM and even then NASA did not give me the figures or tables for the
document. You can verify what I have stated is true through MSFC's RSRM
project office. You will have to find an engineer who was there at the time
of the accident. I know one. The SRM chamber pressure accuracy debacle led
directly to the requirement to place all future SRM pc measurements under
configuration control.

Not back then, I must agree. Does that make it okay during steady state
burn?

Yup. 1,5, and 12 sps is more than adequate for post-flight ballistic
reconstruction. Kinda stinks for blips and ignition transient, so that's
why we're lookign at bumping it up by more than an order of magnitude.


Yes for the ignition transient, the data rate for STS 51-L was wholly
useless. To this day NASA can not definitively state what really happened
pressure-wise in that first 600 milliseconds other than the boosters did
ignite and pressurize. NASA used data from other flights in their charts
pertaining to the ignition transient. IIRC they never showed a single
chamber pressure data point from 51-L data for that time when the black
smoke first appeared.


Today I sort of doubt you have those spreads between the xducers.

Same data rates today. Our traces don;t have the jagged appearance because
int he data you've presented, the 3 xducers are displaying data at all
time points. To clean up the data, just delete the cells that have the
extraneous data (such as, say, B14-B16, B19-B21, C14-C25, etc.)


Ya, I know. I have done much more than clean up that data. I have actually
gone in and separated out the two different data streams that NASA used to
generate the first second of 51-L data following T=0. I have also treated
the rest of the data the same way and the results are quite interesting.

Quality high rate data is three things:

1. Expensive
2. Heavy
3. Processor intensive

Nevertheless, if one is going to stake a report on data like that to which
I have referred, it should be honestly presented, accurate within a
tolerance that makes the data truly relevant,

The data presented looks to be fully in compliance with what would have
been actually recorded. You can't present data that *wasn't* recorded.


Okay, we can discuss this more later, but if it is compliant then how come
the data is recorded at a variable data rate throughout the flight?


Now one more thing, looking at the data, what interpretive value would you
place on it during the first second following T= 0?

I'm not sure what you're after. If you're askign if it looks right... yes,
it does. A spike followed by a dip in pressure follwed by a climb back up.
This is normal in *many* solid rockets: the igniter fires and quickly
pressurizes the case; the case begins to blow down, and then the main
propellant gets up to speed and drives the pressure back up.


Umm, I just wondered if you noticed the data rate was 25 samples/second and
that it changes many times thereafter?

If you delete the extraneous data, you'll see that the transducers aren't
grabbing data at the same time, but are offset by some milliseconds. This
also addes to the apparent lack of co-ordination between them, as the
pressure was constantly changing, and they weren;t reading it at the same
time.


I wish it were so simple. Of course I hope others here will look at the
data too, and add their comments.

Daniel


  #73  
Old March 7th 05, 08:44 AM
OM
external usenet poster
 
Posts: n/a
Default

On Sun, 06 Mar 2005 19:59:14 GMT, Scott Lowther
wrote:

I will look forward to that. Since I'll be responsible for analyzing the
ballistics of the two SRB's from the forthcoming launch in May, it
should be interesting to see what you have... and how you interpret it.


....How *he* interprets it? Are you willing to undergo the same level
of psychochemical abuse, Scott?

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
  #74  
Old March 7th 05, 03:16 PM
Scott Lowther
external usenet poster
 
Posts: n/a
Default

Charleston wrote:


If you
look at the first second of data again you will see that there are 25 data
points.

That is an artifact of presentation. There are multpile xducers reading
at different rates. In order for Excel to plot them all on the same
graph, whoever compiled the data chose to give all three xducer readings
a single "time" column. As a result, every Xducer had it'd data
repeated. In the case of the 12.5 sps xducers, that meant repeatign each
data poitn twice. Note that in the first second, when pressure was
ramping up, the data for 1302 and 2302 was paired.



That first second of data is farcical

No. It's just presented poorly. Take out every other data poitn for 1302
and 2302. This is the result of having different sample rates and trying
to smash them all on the same graph.

So again I ask what is your read of the data rate for the STS 51-L flight
data on my website?


1,5, and 12.5 (not 12, as I said before). Again, look at the initial
ramp-up, and note the repeated readings.


Ah yes precision and accuracy, first year chemistry, thanks. Accuracy is
indeed another matter. I expect that NASA would have a standard and indeed
they did. The CEI requirement was +- 15 PSI but there was no requirement to
actually calibrate the pressure transducers.

That seems massively unlikely. Did you look at the specifications for
the *transducers?* How about the work processes?


Not back then, I must agree. Does that make it okay during steady state
burn?


Yup. 1,5, and 12 sps is more than adequate for post-flight ballistic
reconstruction. Kinda stinks for blips and ignition transient, so that's
why we're lookign at bumping it up by more than an order of magnitude.



Yes for the ignition transient, the data rate for STS 51-L was wholly
useless.

Not *wholly*, just annoyingly lean.


To this day NASA can not definitively state what really happened
pressure-wise in that first 600 milliseconds other than the boosters did
ignite and pressurize.

And they did so nominally. Thing is, somethign goes funny at ignition,
funny enough to cause trouble, and it'll show up. Motors like the
Shuttle SRM are pretty stable... mess with them, and they'll settle back
down. To mess with them enough to cause trouble, you'd *really* have to
mess with them. Block the throat with a car-sized chunk of propellant,
that sort of thing. And that shows up.


Quality high rate data is three things:

1. Expensive
2. Heavy
3. Processor intensive

Nevertheless, if one is going to stake a report on data like that to which
I have referred, it should be honestly presented, accurate within a
tolerance that makes the data truly relevant,



The data presented looks to be fully in compliance with what would have
been actually recorded. You can't present data that *wasn't* recorded.



Okay, we can discuss this more later, but if it is compliant then how come
the data is recorded at a variable data rate throughout the flight?


As I said, I only really looked at the data for the first secodn or two.
Where do you see variability in the data rate?



Now one more thing, looking at the data, what interpretive value would you
place on it during the first second following T= 0?



I'm not sure what you're after. If you're askign if it looks right... yes,
it does. A spike followed by a dip in pressure follwed by a climb back up.
This is normal in *many* solid rockets: the igniter fires and quickly
pressurizes the case; the case begins to blow down, and then the main
propellant gets up to speed and drives the pressure back up.



Umm, I just wondered if you noticed the data rate was 25 samples/second

Not in the first second. I'll look at later times... later.


and
that it changes many times thereafter?



If you delete the extraneous data, you'll see that the transducers aren't
grabbing data at the same time, but are offset by some milliseconds. This
also addes to the apparent lack of co-ordination between them, as the
pressure was constantly changing, and they weren;t reading it at the same
time.



I wish it were so simple.

Actaully, it is, if you know you need to do it. I've not yet doen this
with a flight RSRM (the job of reconstructing flight data circulates,
and let's face it, the flight rate hasn't been that high lately), but I
have with static test data, where the data rates are *far* higher. Trust
me, trying to make sesne out of several different transducers reading at
different but hundred+ sampels per second rates is a pain. I've had it
crash Excel numerous times. Flight data will be a snap in comparison.
  #75  
Old March 7th 05, 04:15 PM
external usenet poster
 
Posts: n/a
Default


Scott Lowther wrote:
Charleston wrote:


If you
look at the first second of data again you will see that there are

25 data
points.

That is an artifact of presentation. There are multpile xducers

reading
at different rates. In order for Excel to plot them all on the same
graph, whoever compiled the data chose to give all three xducer

readings
a single "time" column. As a result, every Xducer had it'd data
repeated. In the case of the 12.5 sps xducers, that meant repeatign

each
data poitn twice. Note that in the first second, when pressure was
ramping up, the data for 1302 and 2302 was paired.


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.

Very '70's.

  #76  
Old March 7th 05, 04:39 PM
external usenet poster
 
Posts: n/a
Default


OM wrote:
On Sun, 06 Mar 2005 19:59:14 GMT, Scott Lowther
wrote:

I will look forward to that. Since I'll be responsible for analyzing

the
ballistics of the two SRB's from the forthcoming launch in May, it
should be interesting to see what you have... and how you interpret

it.

...How *he* interprets it?


So long as the data is presented honestly... data is data.
Interpretation can be interesting, though. So far the data appears to
be valid, and includes the rather annoying duplication of data involved
with trying to smash multiple and poorly-synchronized readings onto one
time-axis.

OK, that was worded badly. But you get the idea.

  #77  
Old March 7th 05, 05:14 PM
external usenet poster
 
Posts: n/a
Default


Scott Lowther wrote:

Following the redesign of the SRBs a higher thrust differential

between the
two boosters was allowed. The data I posted reflects rather

sensitive
instrumentation with three significant figures right? Given the

resolution
of the xducers at 1/1000 of a PSI, what do you suppose the actual

accuracy
is in PSI?

*Precision* may be down to milli-psi, but *accuracy* is another

matter.

I will also point out that the way these (and most, I imagine) pressure
transducers work is to generate a voltage, and then convert that
voltage into a psi reading. During calibration, a "X millivolts = Y
psi" factor is worked out for each xducer. So even though you might see
a reading with numerous decimal points... 892.347 psi, say, what you
are actually seeing is what the conversion factor makes of, say, 68
millivolts. There's a lot of psi between 68 and 69 millivolts, so you
don't get the pressure readings between them. And yet you still wind up
with all those decimal points.

Them's the breaks when you use a digital system.

  #78  
Old March 7th 05, 09:09 PM
D Schneider
external usenet poster
 
Posts: n/a
Default

OM om@our_blessed_lady_mary_of_the_holy_NASA_researc h_facility.org wrote:

[...]
Again, kids, please. Just killfile every M***** and put them out of
our misery. Don't waste your time on them.


Acutally, I'm finding Scott's discussion of the data to be pretty
interesting. I'm hoping also that Mary will chime in, as the data streams
she has dealt with undoubtedly have artifacts and other details that must
be dealt with before interpreting the data.

/dps


--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
  #79  
Old March 7th 05, 09:29 PM
Herb Schaltegger
external usenet poster
 
Posts: n/a
Default

In article opsm9990gdemtzlb@d3h1pn11,
"D Schneider" wrote:

OM om@our_blessed_lady_mary_of_the_holy_NASA_researc h_facility.org wrote:

[...]
Again, kids, please. Just killfile every M***** and put them out of
our misery. Don't waste your time on them.


Acutally, I'm finding Scott's discussion of the data to be pretty
interesting. I'm hoping also that Mary will chime in, as the data streams
she has dealt with undoubtedly have artifacts and other details that must
be dealt with before interpreting the data.

/dps


So am I. I have downloaded Daniel's spreadsheet but I've done nothing
more than glance through the data; paying work beckons and all that.
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.

--
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
  #80  
Old March 7th 05, 09:38 PM
Henry Spencer
external usenet poster
 
Posts: n/a
Default

In article .com,
wrote:
...During calibration, a "X millivolts = Y
psi" factor is worked out for each xducer. So even though you might see
a reading with numerous decimal points... 892.347 psi, say, what you
are actually seeing is what the conversion factor makes of, say, 68
millivolts. There's a lot of psi between 68 and 69 millivolts, so you
don't get the pressure readings between them. And yet you still wind up
with all those decimal points.


Only if the software doesn't judiciously round off the value to reflect
the limited precision of the original data. Keeping all those decimal
places is simply silly -- a waste of bytes and (as we've seen) a boobytrap
for incautious analysts -- but carelessly-written software *is* common.
--
"Think outside the box -- the box isn't our friend." | Henry Spencer
-- George Herbert |
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Lessons Learned but Forgotten from the Space Shuttle Challenger Accident Jim Oberg Space Shuttle 0 December 13th 04 05:58 PM
Lessons Learned but Forgotten from the Space Shuttle Challenger Accident Jim Oberg History 0 December 13th 04 05:58 PM
"Hindsight bias" could hide real lessons of Columbia accident report,expert says (Forwarded) Andrew Yee Space Shuttle 0 September 3rd 03 01:54 AM
NASA Administrator Accepts Columbia Accident Report Ron Baalke Space Shuttle 3 August 27th 03 04:48 PM
Columbia Accident Investigation Board Releases Final Report Jacques van Oene Space Shuttle 0 August 26th 03 03:30 PM


All times are GMT +1. The time now is 12:25 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 SpaceBanter.com.
The comments are property of their posters.