New FDR Decode

Originally posted by tezzajw

Originally posted by R_Mackey
Well since 911Files only exists in quote form to me, through others,

Originally posted by 911files
Darn Mackey imposter, we were talking about England, not me. Thought you had me on ignore?

You must be working so hard on that alleged FDR data decode that you don't read posts properly, 911files?

Don't pick on him tezz, he claims to be an old man and seemed a bit upset when Turbofan picked on him.

Be nice to 911Files. After all his miscalculations and completely absurd theories, you have to feel sorry for the guy at some point.

Originally posted by 911files
reply to post by tezzajw

 

No, you must not be. Please show me where my reference to an 'old man' was quoted by anyone in the thread above please.

You're confusing me with someone else, 911files. Perhaps the time and effort that you're spending on the alleged FDR data is hindering your ability to correctly reads posts?

I never stated anything about you being an old man. Quote me if you think that I did.

How can the alleged FDR data show the flight deck door always being closed, 911files? I'm puzzled by it!

Originally posted by R_Mackey
How does a DFDR record 42 hours of data when it is only rated to record 25 hours?

Poseurs who don't understand roundoff error, linearity, or
the word "approximate" can't be expected to understand the
word "minimum" either. From the NTSB Specialist's Factual
Report of Investigation, Digital Flight Recorder, NTSB
Number DCA01MA064, 31 January 2002, my emphasis:

A minimum of the last 25 hours of operational data is retained on the recording medium.

Translation: The number of hours recorded is at least 25,
but may be greater than 25 depending on the effectiveness
of the compression and encoding algorithms.

Note also that the report cited above lists FLT DECK DOOR
(port EICAS L/R-A-1) as one of the "Parameters Not Working
or Unconfirmed".

That was more than 6 years ago. I guess some people just
need a longer runway than others.

Will

cesura/Will/Claimed Phd from MIT,

You may want to Google FA2100 and get the specs directly from L3. Seems you have a habit of ignoring the manufacturer of the FDR.

Also, "Minimum" does not mean "almost twice the amount".


But then again, you also thought the nose would be a perfectly fine point used exclusively to determine spatial orientation of an aircraft.

Originally posted by cesura
Note also that the report cited above lists FLT DECK DOOR
(port EICAS L/R-A-1) as one of the "Parameters Not Working
or Unconfirmed".

As is the Radar Altitude you claim supports an impact.

[edit on 27-11-2009 by R_Mackey]

Originally posted by tezzajw

Originally posted by 911files
reply to post by tezzajw

 

No, you must not be. Please show me where my reference to an 'old man' was quoted by anyone in the thread above please.

You're confusing me with someone else, 911files. Perhaps the time and effort that you're spending on the alleged FDR data is hindering your ability to correctly reads posts?

Now this is why you are confused all the time.

Originally posted by tezzajw

Originally posted by R_Mackey
Well since 911Files only exists in quote form to me, through others,

Originally posted by 911files
Darn Mackey imposter, we were talking about England, not me. Thought you had me on ignore?

You must be working so hard on that alleged FDR data decode that you don't read posts properly, 911files?

You assert I am not reading well because Mackey imposter claims to only be reading my quotes. I ask you to show me the quote by anyone where I am talking about an old man to support your assertion. Instead, you go off on another tangent. This is why you stay confused.

[edit on 27-11-2009 by 911files]

Originally posted by cesura
That doesn't correlate with radar, terrain, and other
data, nor is it consistent with the longitudinal
acceleration recorded at the same time.

Yes, well your internet "say so" and $7 US will get me a cup of coffee at Starbucks. Which radar, what "terrain, and other data" are you talking about here? Does anyone have any supporting documentation, maps, charts, spreadsheets, etc. to support these assertions, or are we all just whizzin' in the wind here?

Your hypothesis would imply at least 8 seconds missing
from the decodes performed by PfT and NTSB, instead of
the 4 seconds implied by hypotheses that correlate with
other data.

This is why it is important to read AND quote in context, Will. If you read the paragraph that quote was excised from, you will see the "scare quotes" and some old Jon Lovitz/SNL shtick. I am aware that sarcasm doesn't often translate to the internet- I'll try to remember the [/sarc] tag next time, but FYI- that really wasn't any "hypothesis" of mine.

Most of us have been merging those four fields (from
three instruments) into a single radio height. Keeping
them separate will give you different rates of descent
for exactly the same reason that separating the stream
of pressure altitudes into four distinct streams, each
one or two seconds out of phase with each of the others,
would give you different rates of descent for each stream.

Yes well "merging" data often results in what I've heard referred to as "convoluted data" or alternately "conflated data," and I was trained to avoid that specifically without proper and well-documented justification for doing so. It's actually slightly similar to that Nyquist "aliasing" thing that we were talking about. But if the corresponding scan intervals between the respective RA's are scanned at the same frequency for a "nearly linear" descent (as I believe you have been suggesting on this thread), then shouldn't the 3 or 4 slopes be very similar taken across several scan cycles? Of course there will be a "time offset" between the different RA sensors, but I seem to recall the scan interval being nearly identical between each set. Unfortunately, I'm still recovering from a computer crash, and I won't have my spreadsheet installed for a while while I save a few backups, so I can't open my earlier work right now.

Lots of people understand linearity. Your grandmother
was one of them.

I highly doubt that you ever knew my grandmother well enough to make that presumption. She only had an 8th grade education and married very young IIRC, but she was a hell of a cook! She quite likely may not have understood most definitions of "linearity" very well BTW.

Originally posted by R_Mackey
Also, "Minimum" does not mean "almost twice the amount".

No one said it did.

On the other hand, compression and Huffman encodings
often achieve factors much greater than two. A factor
of 1.68 is hardly unusual.

But then again, you also thought the nose would be a perfectly fine point used exclusively to determine spatial orientation of an aircraft.

Untrue. Both you and tezzajw have been "forgetting"
to mention the 3-dimensional vector that goes along
with that point. Both of you also have a habit of
ignoring words such as "about" and "approximate". For
example, I stated that even greater accuracy could be
achieved by adding a second 3-dimensional vector to the
point+vector representation, but that information was
not available with version 1.3 of Warren's decode.

As is the Radar Altitude you claim supports an impact.

One of the four radio height parameters I've been graphing
appears in that list, but its values are consistent with
the three primary radio heights. Hence none of my arguments
would be affected by ignoring it.

In any case, my calculations do not depend upon radio
height or pressure altitude; I show the recorded radio
heights and pressure altitudes only when graphing my
calculated values against FDR data.

Will

Originally posted by rhunter
I highly doubt that you ever knew my grandmother well enough to make that presumption. She only had an 8th grade education and married very young IIRC, but she was a hell of a cook! She quite likely may not have understood most definitions of "linearity" very well BTW.

I'm reminded of an old saying in the Back Bay of Beantown...

"There is a reason MIT PhD's never get invited to a Northeastern U party and eventually become only employed by NU...."



Sorry Will, couldn't resist. But you may want to tone down the pompous attitude a bit. Especially when you been proven wrong time and time again in this thread.

Originally posted by cesura
One of the four radio height parameters I've been graphing
appears in that list, but its values are consistent with
the three primary radio heights. Hence none of my arguments
would be affected by ignoring it.

Very good Will, so certainly the other RadAlt parameters are listed under "Parameters Plotted"? Hence "Confirmed", as is the Pressure Altitude?

Will, why do you cherry pick so much? Is it to fill an agenda?

Will, do you personally seek govt grants?

[edit on 27-11-2009 by R_Mackey]

Originally posted by cesura

Originally posted by tomk52
I recognize the theoretical Nyquist criterion. I am neither a mathematician nor a scientist. I'm an engineer. I'll stick with 8x whenever possible. And move carefully down to 5x when forced to.

Entirely appropriate. The mathematical theorem says the Nyquist frequency is exactly 2x, but that theorem also says its conclusions hold only when the signal is bandwidth-limited to less than the Nyquist frequency. In most engineering applications, you won't have exact knowledge of the bandwidth, so you have to build in a margin of safety.

I got snaked a bunch of years ago on this very issue. I was trying to record some high frequency waveforms out of an RF generator. I'd read about Nyquist criteria and designed the DAQ system (a LabView system, just like rhunter is about to bring up) for 4x the generator freq. I thought I'd discovered all kinds of problems with "out of acceptable frequency emissions". I showed my results to a old timer EE. He took one look, told me to double the DAQ frequency, and all my "discoveries" suddenly evaporated.

Originally posted by cesura

Originally posted by tomk52
The Moire effect is registered just fine by film, by cameras, by photoelectric cells, etc. Not only by biological visual systems. Therefore it is not caused by our visual systems. It's an objective phenomenon that is a spatial analog to "beat frequencies" in superposed oscillating systems with slightly different frequencies..

The Moire effect is a special case of aliasing, which is the objective phenomenon registered by all those systems: there are infinitely many signals that give rise to exactly the same data when sampled.

Agreed. I was just intending to point out that it didn't ORIGINATE within our visual system. That the aliasing (or interference pattern) exists as a result of external, objective phenomena.

Originally posted by cesura
The mistake arises only when someone or something tries to impose some interpretation on that data, and chooses the simplest (low-frequency) interpretation instead of considering signals at or above the Nyquist frequency. It's basically an inappropriate use of Occam's razor.

Or on occasion, when you impose the phenomenon to get the right answer.

During this discussion, the oldest (in my experience) & very useful example of a very simple Moire pattern (a single line pattern) occurred to me: Vernier scales on old-time calipers.

Originally posted by cesura
Humans make that mistake quite naturally; it seems to be part of our cognitive programming. Computers and other devices can make that mistake also, but only when they're programmed to do so. That's an important difference between humans and computers: Computers are generally willing to regard data as mere data, without expressing or trying to defend any opinion regarding the original signal from which the data were sampled.

We are pattern recognizers without peer on the planet. Unfortunately, that gets us to seeing all kinds of patterns that really aren't there.

Including dragons in random cloud shapes, Jesus in grilled cheese sandwiches, and conspiracies in random events.

Originally posted by cesura
I haven't been trying to prove you wrong. I've just been trying to explain why I don't understand your point.

Will

Ditto.

I hope you had a great Thanksgiving.

Tom

Originally posted by R_Mackey
Sorry Will, couldn't resist. But you may want to tone down the pompous attitude a bit. Especially when you been proven wrong time and time again in this thread.

I must have missed that. Everything I have seen tends to show you wrong time and time again. For example.

The FDR stores serial bit data. For you Mackey imposter, that means an applied votage greater than the carrier voltage = binary 1. The absence of that voltage is the binary value 0. In other words, no signal = 0, signal = 1. Here is the frame segment for the FLT DECK DOOR.

[atsimg]http://files.abovetopsecret.com/images/member/ab67934c46c9.jpg[/atsimg]

Note, binary 0 is translated to mean CLOSED. However, what it means is that no signal was being sampled in that frame for that parameter. Since there is no evidence that a signal was EVER sampled for the 42 hours recorded, it can be assumed that this bit was not being sampled (since we know that at some point in 42 hours someone would most likely have opened that door).

[edit on 27-11-2009 by 911files]

Originally posted by tomk52
Unfortunately, that gets us to seeing all kinds of patterns that really aren't there.

Including dragons in random cloud shapes, Jesus in grilled cheese sandwiches, and conspiracies in random events.

Certainly to include Puff The Magic Dragon, Santa Claus, the Easter Bunny and an aircraft impacting the Pentagon?

You left yourself wide open for that one Tom. You gotta admit...

Originally posted by tomk52
...
I agree wholeheartedly that Balsamo is a pompous ass.

BTW, Tony Sz is not a structural engineer. He is, like me, a mechanical engineer.

He's just not nearly as good a MechE as I am. And his theories are riddled with nonsense.

TomK

Now this quote is somewhat peculiar. How many MechE departments teach signal processing and capture/DAQ as part of their curriculum? I seem to recall that being a primarily EE (or possibly CS) endeavor with most of the universities that I'm aware of, and certainly with an overwhelming majority of the engineers that I have worked with over the years.

Anyway, we've now got the "tomk52 theorem" of 5x-8x "over"sampling of signals to prevent aliasing- you heard it first here at ATS. Perhaps a formal paper will be forthcoming at some point in the future.

Much of engineering ultimately comes down to economy, unfortunately. How much data analysis, money, time, equipment, and bandwidth would be wasted by increasing the dataset size by 2.5-4x? Those numbers would probably be fairly difficult to quantify.

Those on government contracts likely wouldn't care from what I have observed in the past.

There is a very strong indication that something catastrophic happened within the last 2 data frames. Here is the longitudinal acceleration versus time to End of Data for the last 6 seconds.

Time Long. Accel.
(sec) (G's)
-6.00 0.177
-5.75 0.169
-5.50 0.130
-5.25 0.165
-5.00 0.171
-4.75 0.132
-4.50 0.141
-4.25 0.137
-4.00 0.134
-3.75 0.145
-3.50 0.143
-3.25 0.124
-3.00 0.175
-2.75 0.130
-2.50 0.139
-2.25 0.139
-2.00 0.187
-1.75 0.210
-1.50 0.200
-1.25 0.181
-1.00 0.173
-0.75 0.210
-0.50 0.014
-0.25 0.118
0.00 -1.083

And here it is plotted:

Graph, Long. accel vs time

We know that the engines were at 100% power, & clearly started accelerating, at about 36 seconds before EoD, quickly reached a max acceleration (0.25 g) at about 24.5 seconds before EoD, and the accel had been steadily decreasing ever since. The accel was decreasing because the drag force was increasing as approximately the square of airspeed.

This relationship (drag vs. airspeed) is why I approximated the longitudinal accel using a 2nd order polynomial. You can see that the polynomial fits the data quite nicely.

The existence of some major event is shown in the accel data at about 2 seconds before EoD, when the longitudinal accel suddenly INCREASES to 0.21g. This increase cannot be explained by added engine power or lowering the nose. We know from vertical accel that Hanjour was pulling the nose up during this interval.

There are two possible explanations:

Choice A: The data is trustworthy
1. This is a structural vibration shooting thru the body of the plane. Remember, the accelerometer (located at the CG of the plane) measure the acceleration of THE ACCELEROMETER itself. (This is "sensors 101".) With the accelerometer bolted to an internal bulkhead of the plane, the acceleration of the accelerometer is usually equivalent to the acceleration of the plane itself. But in the case of an impact, the various substructures will all have their own accelerations, and the accelerometer will record the acceleration of the component to which it is attached.

This fact is corroborated by the fact that, at the last accelerations listed, the final airspeed would have increased from 481 kts to 492 kts. Instead, it increased from 481 kts to only 483 kts, for an average longitudinal acceleration over this interval of 0.046g. (Note that this is only 1/3rd of the 0.13g acceleration that it had been maintaining just before the event.

So it is clear that after this event, whatever it was, the plane was unable to maintain the full power longitudinal acceleration that it had maintained for the previous 22 seconds.

Choice B: The data is untrustworthy
2. It is an electrical glitch due to an interruption in the electrical power. And all the data has gone somewhat squirrelly.

Regardless of which choice you take, the conclusion is clear. Somewhere around 1.75 to 2.25 seconds before impact, something catastrophic happened to the data being provided to the FDR by the plane's sensors.

TomK

Here's a little tech for those interested. The Flight Deck Door was most
certainly assigned as a recorded parameter as per this chart:

[atsimg]http://files.abovetopsecret.com/images/member/48915ff55790.jpg[/atsimg]

[atsimg]http://files.abovetopsecret.com/images/member/f6bffbbcaaee.jpg[/atsimg]

A port that is not used looks like this in the documentation:

[atsimg]http://files.abovetopsecret.com/images/member/c503c27cb4d9.jpg[/atsimg]

It is clear, without debate that Flight Deck Door was assigned and being
polled by the system.

These captures were taken from a Boeing 757 manual, document number:
D226A101-3, revision G.

As shown the flight data recorder receives a logic low (binary 0) when the
door is closed. With electronic circuits (specifically digital signals), you
must NEVER leave a pin open. It must be referenced to VSS (signal high),
or Ground (signal low) at all times. It CANNOT remain floating or the input
circuitry will receive noise, and/or an undetermined value.

For this reason, the following circuit is the standard for switched logic
circuits. There may be variations, however the signal input line will
ALWAYS sense Ground (logic 0), or VSS (logic 1)

[atsimg]http://files.abovetopsecret.com/images/member/41ef709bc16d.jpg[/atsimg]

So what does this mean? Well, according to the documentation, the door
is closed when a logic zero is received at Port D14, word 251, bit 1, subframe 3.

If this parameter was NEVER recorded the documentation would not assign
a port, and/or a word/bit position.

If the door was left open, the value would read logic 1 (VSS) as shown on the right side (Figure 2).

Parameters that are not recorded (IE: spares, or unused ports) are tied
to ground instead of VSS to reduce current draw and power consumption
in a circuit.

Summary:

Unused pins, spare ports, etc. are tied to ground and are labelled as spare
in the second chart from the top of this post.

Assigned parameters are never 'floating' and will either see a logic 1, or
logic 0. In the case of the Flight Deck Door, it was reading ground which
means it was closed (logic 0).

[edit on 28-11-2009 by turbofan]

Originally posted by cesura
Untrue. Both you and tezzajw have been "forgetting"
to mention the 3-dimensional vector that goes along
with that point. Both of you also have a habit of
ignoring words such as "about" and "approximate". For
example, I stated that even greater accuracy could be
achieved by adding a second 3-dimensional vector to the
point+vector representation, but that information was
not available with version 1.3 of Warren's decode.

You stated that a single point and a velocity vector were sufficient before you mentioned anything about approximate values derived from pitch, roll and yaw.

You'll need to quote me on the false statement that you've just made about me, cesura. It's obvious that you've misread my posts. Go back and read the post. Nice try at back-pedalling.

Your single point-velocity vector are not sufficient for an accurate flight path. That's why more position coordinates are needed or the pitch, roll and yaw vales.

Originally posted by tomk52
There is a very strong indication that something catastrophic happened within the last 2 data frames. Here is the longitudinal acceleration versus time to End of Data for the last 6 seconds.

Nice graph TomK. Just for reference, our scales are a little different. I've labeled the final subframe as 0 because my work has been focused on positional and the final recorded INS position is my primary interest. For those wishing to correlate the two scales, the final correlated INS position (over Rt. 27) would be at -0.75.

Originally posted by turbofan
Assigned parameters are never 'floating' and will either see a logic 1, or
logic 0. In the case of the Flight Deck Door, it was reading ground which
means it was closed (logic 0).
[edit on 28-11-2009 by turbofan]

Nice technobabble turbo, and mostly true, but that is not how a serial bit stream works. Logic 0 means no signal on the carrier.

The ONLY evidence you can show that the FDR was recording that parameter is to show us evidence of a logic 1. Please, you have 42 hours of data, surely the door was open at least once. Should be easy for you to demonstrate me wrong.

[edit on 28-11-2009 by 911files]

Originally posted by rhunter

Originally posted by tomk52
...
I agree wholeheartedly that Balsamo is a pompous ass.

BTW, Tony Sz is not a structural engineer. He is, like me, a mechanical engineer.

He's just not nearly as good a MechE as I am. And his theories are riddled with nonsense.

TomK

Now this quote is somewhat peculiar. How many MechE departments teach signal processing and capture/DAQ as part of their curriculum? I seem to recall that being a primarily EE (or possibly CS) endeavor with most of the universities that I'm aware of, and certainly with an overwhelming majority of the engineers that I have worked with over the years.

Anyway, we've now got the "tomk52 theorem" of 5x-8x "over"sampling of signals to prevent aliasing- you heard it first here at ATS. Perhaps a formal paper will be forthcoming at some point in the future.

Much of engineering ultimately comes down to economy, unfortunately. How much data analysis, money, time, equipment, and bandwidth would be wasted by increasing the dataset size by 2.5-4x? Those numbers would probably be fairly difficult to quantify.

Those on government contracts likely wouldn't care from what I have observed in the past.

Spoken like a true baby tech.

Some people DO continue to learn things after college, ya know.
I got my BSME in '74. I've been learning things on the job ever since.

Look, kid.

I told you what to do. Go ask ANY experienced EE, or any apps engineer at NI, what level of oversampling they'd recommend.

When they tell you "about 8x", c'mon back here again with your snarky 'tude.

TomK.

Originally posted by 911files

Nice technobabble turbo, and mostly true, but that is not how a serial bit stream works. Logic 0 means no signal on the carrier.

[edit on 28-11-2009 by 911files]

Actually it's entirely true. The signal you speak of in this case is TTL level
Direct Current...or 5 Volts DC.

When the Data Acquisition unit polls port D14 at any time, it will sense
either a ground, or VSS.

This information is held in a buffer and read into the word structure.

It is then passed onto the SSFDR.

If the port showed a logic 0 (ground) at the time of polling, then bit 1 of
word 251 is set to ZERO and clocked out to the data recorder.

If the port showed a logic 1 (VSS) at the time of polling, then bit 1 of
word 251 is set to ONE and clocked out to the data recorder.

There is no other way around this in Base 2. It's either 1, or 0.

reply to post by turbofan

Originally posted by turbofan
reply to post by tomk52

 

Wow Tom, thanks for opening your ignorant "internet mouth" again.

Let me see if I can recap the list of errors you have made in the last
two posts:

1. There is nothing fancy about the word "electric". It is what, it is...

No kidding. I guess "recognizing sarcasm" is another characteristic that we can drop from your short list of "long suits".

Originally posted by turbofan
2. ...blah, blah, blah ...

3. There is NO error associated with the device as you claim because
it's not even the SAME FREAKIN' INSTRUMENT!

There is an error in EVERY reading taken by EVERY instrument ever constructed.

Originally posted by turbofan
4. Do you know what an ABSOLUTE PRESSURE SENSOR is? I really
did expect you to understand the difference between absolute and gauge values.

Hint: It has nothing to do with "absolute readings"

content.honeywell.com...

Are you claiming that this is the make & model pressure sensor that provides the 757's FDR with its PA & VSI readings?
If not, why don't you post the manufacturer/make/model of the sensor(s) that provide PA & VSI to the FDR.

Originally posted by turbofan
IE: A change in altitude in one second MUST reflect the change in
vertical speed in one second.

Ahhh, so close. But no cigar.
First off, stop using the ill-defined, wiggle-room words like "reflect". Those who know what they are talking about use specific terms. Like "equal to", "proportional to", "proportional to the inverse square"... You get the idea. Maybe.

The change in altitude in one second must be equal to the average vertical speed over that second.
(NOT "reflect the change in vertical speed". The specific word that is WRONG is "... change in ...")
The "change in vertical speed" is equal to the vertical acceleration.

Such frequent sloppiness...


TomK