|
|
Thread Tools | Display Modes |
#71
|
|||
|
|||
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
|
|||
|
|||
"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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 | |
|
|
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 |