|
|
Thread Tools | Display Modes |
#91
|
|||
|
|||
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 |
#92
|
|||
|
|||
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 |
#93
|
|||
|
|||
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. |
#94
|
|||
|
|||
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 |
#95
|
|||
|
|||
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 |
#96
|
|||
|
|||
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. |
#97
|
|||
|
|||
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 |
#98
|
|||
|
|||
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. |
#99
|
|||
|
|||
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. |
#100
|
|||
|
|||
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. |
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 04:58 PM |
Lessons Learned but Forgotten from the Space Shuttle Challenger Accident | Jim Oberg | History | 0 | December 13th 04 04: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 |