Re: BWAAHAHA!!! 51L questions answered...

From: Charleston (charleston1_at_coxthedotgoeshere.net)
Date: 03/12/05 

Date: Sat, 12 Mar 2005 00:09:54 -0800

<lexcorp@ix.netcom.com> wrote:

> Had a nice long conversation with a co-worker about STS-25 SRM pressure
> data that was recently discussed here, and got a lot of clarification.
> To this day the data transmission system is loaded with restrictions
> from the 70's that determine what data is sent back; there are
> consequently minor gaps in the data that aren't gaps at all.

> Unlike today, onboard memory was damned hard to obtain back then, so
> systems were put in place to reduce the volume of pressure data
> transmitted back to the ground as much as possible.

192KB/s downlink data stream IIRC.

> Consequently, if a
> pressure transducer had the same reading (say, 500 psi) for several (3
> or more) readings in a row, the transmitter would only send the first
> and last reading down. A simple subroutine on the ground would look for
> those gaps, and then fill them back in.

Ah, where on the ground?

> Simple. But, if you didn't know
> what you were looking at, and didn't know who to ask, and were looking
> for evidence of a coverup anyway... that lack of data could be seen as
> Evidence Of Malfeasance.

Is the data raw or was it processed by the JSC MCC? Do you really know?

My request to MSFC was for raw data but as it turned out that can not by
definition be what I received as it includes data that was positively not in
the raw data dump and it is not likely in the original "as transmitted"
format either. I was careful early on to cite the source of the data as
coming from a VAX computer using Minitab statistical software from MSFC.
Exactly why you would now suggest that such data would be in its raw form
and therefore be based on an unprocessed algorithm seems to be based more on
a need you have to make some facts that someone told you--work in this
setting. I can no more verify your "nice long conversation" than you can
verify mine. I can however produce a witness and contemporaneous notes.

I can also refer you to the PC Report
http://history.nasa.gov/rogersrep/v2appj.htm

Page J23

"Playbacks of MCC data from the STS 51-L launch were analyzed by a second
ascent flight control team on January 29 and January 30, 1986. The playbacks
used various sources and synchronization processing.

****By using minor frame validation, loss of signal (LOS) was extended from
1 minute 11 seconds to I minute 13 seconds.***

No trajectory processing was available for the seven playbacks on January
29, but two playbacks were accomplished on January 30 with active trajectory
processing. A checkpoint was established for trajectory analysis that picks
up at L-5 minutes for future use, if necessary."

Let me interpret that please. No data was seen in real-time beyond MET
1M:11S. Any data beyond that time was only reviewable after some minor
frame validation issues were corrected at JSC by the Flight Ops Team. Given
that the data I was provided by MSFC goes beyond MET 1M:11S, there is no
question that any algorithms in place were applied on the ground during MCC
processing and all of that data should in fact be present based on your own
information regarding that simple ground subroutine.

Let me add that the last 600 milliseconds of usable data from the Orbiter
was actually processed manually. The SRB data at least from the right SRB
ended at 73.14 seconds (it was therefore extracted without any algorithm of
any kind) when the electrical connection transmitting the data to the
orbiter was severed. The left SRB may have provided data after that time.
Nevertheless, the data provided to me and provided for your review continues
beyond the timeframe in which either SRB could actually be transmitting
anything to the orbiter's computer (hence the red colored boxes where I
disqualified the data as not reasonably obtainable).

There are a number of other discrepencies in your assumptions and the
algorithm you are trying to apply does not work consistently throughout the
data. I will be pointing out the other discrepencies to the group in a few
days as it will take a little time to work on and I have personal
obligations this weekend.

Did the data from the 5 s/s and 1 s/s xducers have similar algorithms? If
not then there should be no blanks in those columns. You do realize that
there are only two possibilites with the data after any blank--it will be
the same as the last data point or it will be different. It does not always
workout the way you suggest. Perhaps this is a selective algorithm to which
you refer although one must wonder how much code that would consume.
>
> Heeheeeheee!!!!

Really?

Daniel

Relevant Pages

  • Re: compressing short XML messages without including dictionary or huffman table
    ... to be transmitted without dictionary/table overhead. ... you were transmitting, you could refer to a specific svg dictionary ... An inefficient algorithm, simply. ... It loses patterns and misses them due to limitations of the ...
    (comp.compression)
  • Re: Cohens paper on byte order
    ... Couldn't one say the same for the quicksort algorithm, ... bits in the AES document and maps them ... Whether these hardware bits are ... has somehow to observe in transmitting 'any' chunks ...
    (sci.crypt)