AA77 FDR Data, Explained

[ktesibios]

Funny- last night I happened to catch a little bit of the History Channel's Modern Marvels program "Enginerring Disasters 20", about the crash of American Airlines flight 587 in Queens on November 12, 2001. Curiosity tweaked, I looked around online for more information, which led to the NTSB accident report at http://www.ntsb.gov/publictn/2004/AAR0404.pdf .

This contains some interesting information about flight 587's FDR. From page 48:

1.11.2 Flight Data Recorder


The accident airplane was equipped with a Fairchild model FA2100 FDR, [NOTE:the same type used in flight 77]
S/N 1186, that was manufactured by L-3 Communications. The FDR used solid-state flash memory, stored in a crash-survivable memory unit, as the recording medium. The FDR was sent to the Safety Board’s laboratory for readout and evaluation.

The FDR showed extensive fire and impact damage. The memory module inside the memory unit did not show any damage, but the memory cable needed to be replaced before the data could be read out.
The FDR contained more than 81 hours of recorded data, and American Airlines provided conversion formulas for the data.84 The FDR recorded about 1 minute 33 seconds of flight data for the accident airplane, beginning at 0914:28.45 (the time that the right main landing gear squat switch changed from ground to air) and ending at 0916:01.23 (before airplane impact).

Footnotes 18 & 20 on page 5 are also of interest (bolding mine):

18 After 0915:58.5, the rudder pedals moved briefly to 0.7 inch right and then to 3.9 inches right, where they remained for the remainder of the FDR recording. (The FDR stopped recording 13.6 seconds before impact.)

20 The rudder angle data detected by the rudder position sensor at the vertical stabilizer were filtered before they were recorded on the FDR. As a result, the rudder angles during the second set of load factor
excursions had to be reconstructed using the recorded FDR data, the characteristics of the filter (as determined from a test performed during this investigation), and constraints imposed by the rudder control system and the recorded motion of the airplane. See section 1.11.2 for information about the data filter and section 1.16.2 for information about the reconstruction of rudder angles.

and on page 55:

However, because of uncertainties in the FDR
data—including data latencies (that is, delays), data filtering, and sampling rate effects— the rudder and sideslip angles at the time that the vertical stabilizer separated from the airplane were determined within a narrow range[/b]—10° to 11° for the rudder angle and 10° to 12.5° for the sideslip angle

But-but- that's impossible! An FDR can't fail to record everything right up to the instant of impact- it's CERTIFIED! And all the data has to be recorded within half a second of its measurement!
COVER-UP! TAMPERING!
WAKE UP BUSH LOYALIST SHEEPLE!

Right, turbofan?

 

[Turbofan]

Right, turbofan?

That's right ktesibios.

You need to stop reading articles and technology you don't understand.

In the case of the Pentagon incident, and the last recorded values
ALREADY STORED TO MEMORY...you can rule out delay and all that
other BS!

If it's in memory and in the file, then too bad, so sad...you can't make
up excuses about delay!

AGAIN, if the parameters read/written before and after RAD ALT are polled
have been safely stored, then our last recorded value was saved and
protected, and read out to be 273 AGL.

Thank you for trying to learn this stuff before debating it.

 

[A W Smith]

Funny- last night I happened to catch a little bit of the History Channel's Modern Marvels program "Enginerring Disasters 20", about the crash of American Airlines flight 587 in Queens on November 12, 2001. Curiosity tweaked, I looked around online for more information, which led to the NTSB accident report at http://www.ntsb.gov/publictn/2004/AAR0404.pdf .

This contains some interesting information about flight 587's FDR. From page 48:


Footnotes 18 & 20 on page 5 are also of interest (bolding mine):




and on page 55:



But-but- that's impossible! An FDR can't fail to record everything right up to the instant of impact- it's CERTIFIED! And all the data has to be recorded within half a second of its measurement!
COVER-UP! TAMPERING!
WAKE UP BUSH LOYALIST SHEEPLE!

Right, turbofan?

Owwwwwhhhhhhh Head shot! You Just shot the freak!

 

[Bananaman]

Ah hell, let's not beat around the bush any more.

Facts are facts. Turbofan doesn't like facts.

But then, Turbofan is insane.

Fact.

Bananaman.

 

[Anti-sophist]

Yes, fantasy buffer in the sense that RAD ALT magically remains in the buffer while all other data is clocked out.

No one said that. It waited in the buffer exactly as long as required by the data-frame layout for its turn in the bit-stream. No more. No less.

If RAD ALT is polled once every second, then you can certainly figure out
that a value was STORED in the crash protected memory (CPM) at least one second before impact.

This is not true. SOME value was stored within 1 second of impact. You are right on that. You might not have that value because it was in a lost frame. Or, that value might not have actually been MEASURED one second before impact, but might be older due to other delays.

The correct statement is:
If the RAD ALT is polled every second than the measured value WAITED IN THE DIGITAL BUFFER for at most one second.

You've come up with T2+T3 = 1 second. Considering we know T2 is equal to 1 second, that means you've assumed T3 to be 0 second.

Furthermore, you have no guarantees that that value in the CPM is less than one second before impact because you don't know that the value you got on your computer is the LAST value because you don't know what frames were lost in decoding the CPM (T5). Nor have you factored in the to-end-of-frame delay (T4).

Also you still don't know how long the RAD ALT took to generate the message (T1).

In order to claim that the last RADALT value in the file you have happened within X time of the impact, you need to justify your estimation of all 5 T values. You don't seem to grasp this and continuously assume most of them are 0.

For T-value explanation: http://www.internationalskeptics.com/forums/showpost.php?p=3849698&postcount=636

YOu see, the data from the sensor passes through the buffer, and down
the serial bus and into CPM within <=500 ms no matter what the poll request for any sensor will be.

This is categorically false. Not only have I proven it false, but you just admitted on the line above that it was at most 1 second old. Now you are saying 500ms? Seems like your own theory is not consistent.

If the RADALT generates a measurement and just missed his time in the bit-stream, that measurement will have to wait 1 full second before it's next chance. 1000 ms > 500ms. What you are describing is not physically possible.

My arguement and the one you are not understanding is, all of the parametersbefore and after RAD ALT have been stored in CPM at least one second before impact.

I understand your argument perfectly. And I've been trying to explain to you over and over and over that the system has delays that you are assuming to be of length 0. Namely T1, T4, and T5.

Once again. Parameters before and after RAD ALT traveled down the serial
bus and were stored.

RAD ALT cannot park itself on the wire, or buffer while other data is clocked
into CPM.

No one has claimed this has happened. None of the parameters jumped ahead of the RADALT. They all wait in the buffer until it's their turn, and then they get stored, in order. They all have an instrument delay (T1). They (the digital ones) all have a digital buffering delay (T2). They all have a write delay (T3). They all have a position inside the frame (T4). And they all could be members of a lost frame (T5).

For some bizarre you think I'm describing some problem specific to the RADALT. Every single digital parameter on the entire plane that goes through the buffer, into the bitstream, into a frame, onto the media, off of the media, into a bit-synch, into a data-frame layout, and onto a computer file has to deal with the exact same ****.

 

[jaydeehess]

As far as I know PfT has only made phone calls to the NTSB and FBI and demanded immediate answers to questions posed over the phone.
That is not how things work in the real world and Balsamo knows this, or at least should know it.


Once again I see that you and PfT and others are very convinced that the DFDR data and the flight path described by the physical damage do not agree. PfT states they make no theory on what actually happened at the Pentagon on 9/11/01. Therefore they, and you if you also claim no theory to what happened, have only the issue that the data is incorrect.

Therefore I ask again why, given the gravity of such a situation in the matter of flight safety, there has not been a technical paper outlining the problems with the recording of the DFDR data?

You completely ignore this it seems. If you have answered this question before please by all means point me to the post and I apologise in advance for having missed it the first time.

.

Seems to me that I have already asked this of Turbofan twice now as have others.
I know what Rob Balsamo's response was to a similar question. He steadfastly refused to even address my suggestion. In an e-mail exchange I asked why I had been banned. No reason was ever given other than that I was a "gov't loyalist'. I pointed out that the last couple of posts that I had made contained no offending remarks concerning any PfT research and only suggestions of how to get the questions they state they want answered, answered.

My first e-mail:
May I ask exactly what the reason is for my being banned? I did not question any point in the work you have done concerning Flight 77 FDR.

What was it that irked you about my suggestions?

JDS

,, followed by:
(bolding new in this renditionTo: Rob Balsamo;

First of all how could I have posted the reply you made when i had been banned before trying to access that thread again? Your complaint makes no sense sir. You ban me and as a result I cannot see the thread then you berate me for not posting the reply in that thread to the Randi forums.

A-S did not say he could not find the data. He said he would not jepordize his friend by asking for it.

However, none of this was the subject of my post on your thread. My posts concerned another way to get your message out, pure and simple. Instead of even considering it you attacked it by coming up with thin reasons not to bother with it.

All you need do is write a consise article entitled "FDR data does match flight path - is FDR data untrustworthy?" and present it to "Aviation Week and Space Technology", "Scientific American", "Technology Review", or even "Discover". How many in the industry read AW+ST sir? How many would be interested to find out that there is a case in which the supposed flight path is not faithfully recorded on the FDR? If you wish to present your case the way you have been doing so far you will get little attention. You may hate that but it is the way of the world. constant accusation of gov't officials (who you have on many occasions said are liars etc.) will not garner you the public review or answers you say you desire just as anyone on P4T who berates other posters will get any questions they ask attended to.

Take my advice, don't take my advice, I truly couldn't care less. I had simply hoped that you were open to suggestions. If not, fine.

Now go check the Randi forum thread. This entire exchange will be there momentarily.

JDS

My latest question to TurboFan has been why such a technical paper has not been drawn up and submitted to the NTSB.

So far he simply ignores the suggestion just as Balsamo ignored the suggestion of doing such a submission to a mainstream publication.

Instead they putz about debating these points on internet forums with the clear bent that the data is not simply incorrect when compared to the physical damage but actually actively manufactured data designed to give a false impression of where the plane was at the given time frames involved.
This then begs a new question; if this manufacturing of data was done for the purpose of placing the plane along a path that it did not actually take why then would the data also not be manufactured to definitively show (in all aspects that PfT et al say is erroneous) that it took the path that is described by the physical damage and many eyewitnesses?

Once again they remain silent on this issue.

It seems they are good at asking questions they do not actually want addressed by the NTSB , choosing instead to ask them of internet denizens, AND very bad at addressing questions posed to them by said internet denizens.

Please TurboFan, prove me wrong, do what is right, and answer the questions I have put to you,and make the same suggestion to the PfT experts and Rob Balsamo that I have made.

 

[beachnut]

... and the official flight path is incorrect.

I'm hoping the rest of the public viewing this forum can see the nice
dance moves going on.

If you mean the path where people saw 77 hit lamppost and impact the Pentagon, then the official flight path is right and proven with thousands of pieces of physical evidence and backed up with hundreds of witnesses.

So the public sees you spewing failed ideas from p4t who are only in this to sell DVDs to people who can not figure out 9/11 in 6 years.

So far you have not show evidence to prove 77 did not hit the Pentagon, the public can see this.

Remember public people who have rational and logical thinking still working, Turbofan is saying people planted the knocked down lampposts that real people saw knocked down by Flight 77.

 

[jaydeehess]

... and the official flight path is incorrect.

I'm hoping the rest of the public viewing this forum can see the nice
dance moves going on.

If you mean the path where people saw 77 hit lamppost and impact the Pentagon, then the official flight path is right and proven with thousands of pieces of physical evidence and backed up with hundreds of witnesses.

So the public sees you spewing failed ideas from p4t who are only in this to sell DVDs to people who can not figure out 9/11 in 6 years.

So far you have not show evidence to prove 77 did not hit the Pentagon, the public can see this.

Remember public people who have rational and logical thinking still working, Turbofan is saying people planted the knocked down lampposts that real people saw knocked down by Flight 77.

The "rest of the public viewing this forum" but no attempt at all to detail the problems of DFDR data to the NTSB.
What's wrong with that picture?

 

[beachnut]

That value is 273 AGL

If you want to argue that the FDR magically lost power, or was interrupted... or the coffee was too cold...or the plane was blue...while the last RAD ALT was writing, then I'll give you an extra second.

That is still TOO high based on distance from the wall and speed of the plane. The g force shows nothing in the way of descent from the recorded altitudewithin the 1, or 2 second time frame.

If 273 feet AGL is correct then the 77 is not 1 or 2 seconds away from the Pentagon! You are WRONG for the nth time. The FDR must be missing the amount of data it takes to get from 273 feet AGL, which could be 370 feet above the impact point. This means the terrorist whose VII for that last seconds was averaging, 3900, 4080, 4920, 5160, 5520, 5520,5640,5760,5880,6120, and 6600, could be less than 4 seconds away which matches your 1.5 DME tirade.

77, is the distance from the Pentagon at 273 AGL, for 77 to hit the lampposts, and impact the side of the building. This is proven by evidence, and witnesses. (thousands of pieces of evidence not even debunked by Turbofan, just ignored!)

The G force is not a factor, you have no idea what the G force should be anyway, and since p4t still have 11.2 G posted as a clear indication they have no idea how to calculate G force! If you understood math and physics you could correct p4t's 11.2 G mistake!

There could be many seconds missing from the FDR. Just as many other times FDR have been missing data, 77 can be missing data, you fall short of making any point, and since FDR have lost data for unknown reasons, you have a problem. For the public watching, there are many examples of FDR having data missing.

p4t/Balsamo make up false ideas about the FDR and you believe them and step out on the limb saying 77 did not hit he Pentagon. A conclusion p4t and Balsamo have not made. They have tricked you into buying their false ideas and you make up the story all by yourself. It looks like your conclusion on 77 is a match with Balsamo's physics of 11.2 G, and Balsamo not knowing the part of the electromagnetic spectrum the RADALT works in, or the fact he has no idea how many feet are in a nautical mile. A record of wrong, and you have joined them!

Balsamo is selling DVDs, money is his goal, he is trying to do it by spreading false information.

 

[Anti-sophist]

My latest question to TurboFan has been why such a technical paper has not been drawn up and submitted to the NTSB.

I've been telling them that the need to draw up a whitepaper on this topic for.. uh.. several years now?

I could give you the snarky reason: because you can't put a whitepaper up on your website and sell it truthers for 15$ a pop.

Offtopic question: Is PfT a non-profit organization? Are they declaring all that income on their taxes? I wonder.

But the real reason is probably because JDX et al. don't view "whitepapers" as the proper way to convey their message. Despite the fact that scientists have been using it for literally hundreds of years. You can tell this because all they do is make DVDs, upload videos, and constantly demand "live" debates. Nowhere in their little strategy does "write our ideas down in a concise and mathematical way" enter. The idea that you can convey scientific ideas in a non-scientific way basically screams psuedoscience.

They likely never will. I don't think they are confident that their data will hold up to professional scrutiny and that's why they specifically demure away from professional methods and professional channels. They don't think professionals will take them seriously (and they are right). So they try to end-run around the scientific establishment and lie directly to the people (wow that sounds familiar... creationism.. anyone).

 

[Turbofan]

If 273 feet AGL is correct then the 77 is not 1 or 2 seconds away from the Pentagon! You are WRONG for the nth time. The FDR must be missing the amount of data it takes to get from 273 feet AGL, which could be 370 feet above the impact point. This means the terrorist whose VII for that last seconds was averaging, 3900, 4080, 4920, 5160, 5520, 5520,5640,5760,5880,6120, and 6600, could be less than 4 seconds away which matches your 1.5 DME tirade.

77, is the distance from the Pentagon at 273 AGL, for 77 to hit the lampposts, and impact the side of the building. This is proven by evidence, and witnesses. (thousands of pieces of evidence not even debunked by Turbofan, just ignored!)

The G force is not a factor, you have no idea what the G force should be anyway, and since p4t still have 11.2 G posted as a clear indication they have no idea how to calculate G force! If you understood math and physics you could correct p4t's 11.2 G mistake!

This is not a question of "IF"! The FDR recorded 273 AGL, and that's a fact.
No changing that.

if you want to argue whether the information was held in the buffer, then
we can go there too.

Keep in mind, this isn't Ethernet; it's a closed loop, predetermined data
set.

YOu don't have nodes dropping off, and on, sending different lengths of data.
This is more like a PLC (programmable logic controller) set up when speaking
in terms of the sensors.

So Anti, your theory is that RAD ALT was held in the buffer for an extra
second because the information was not ready at poll time?

You are also stating there may, or may not be propagation delay, correct?

Lastly, do you believe that the last string of data stored in CPM reflects
the "impact time of the object"?

 

[Anti-sophist]

This is not a question of "IF"! The FDR recorded 273 AGL, and that's a fact.
No changing that.

Yes, it is a fact that the FDR recorded 273 AGL. To claim that the plane was actually at 273 AGL at that point and time, though, is not.

if you want to argue whether the information was held in the buffer, then
we can go there too.

There is no argument. I've already shown you the schematic.

Keep in mind, this isn't Ethernet; it's a closed loop, predetermined data
set.
YOu don't have nodes dropping off, and on, sending different lengths of data.
This is more like a PLC (programmable logic controller) set up when speaking
in terms of the sensors.

That barely makes sense. It's an awful analogy. But ok.

So Anti, your theory is that RAD ALT was held in the buffer for an extra
second because the information was not ready at poll time?

No. First, I have no theory. I am describing to you the mathematical reality of the system. Second, it didn't sit there "an extra second". ALL (digital) samples sit in the buffer before entering into the bit-stream. This delay, in the buffer, is at most 1 second (for samples that occur at 1 sample per second).

This is an inescapable mathematical fact:
Given only the knowledge that something enters the bitstream once per second, it can be up to 1 second old.

You are also stating there may, or may not be propagation delay, correct?

I have no idea which portion of the system you are refering to. There may or may not be instrument delay (which we could call propagation). There is certainly a propagation delay along the wire from the instrument to the buffer (although this delay is almost certainly so low that it can be safely ignored). There is also certainly a propagation delay between entering the bit stream and being recorded to the media.

Lastly, do you believe that the last string of data stored in CPM reflects
the "impact time of the object"?

Not really because I don't understand what "last string of data" actually means. The data is only useful when it's in a frame. And odds are whatever you think the "last string of data" is in your files wasn't was actaully the "last string of data" the recorder wrote. You've just ASSUMED that it was, without ever bothering to determine if this was true.

 

[Jonnyclueless]

"You need to stop reading articles and technology you don't understand."

Oh the irony...

 

[beachnut]

This is the 500 millisecond stuff? Look at the power interruption stuff! This show a FDR can have data missing! Debunked by ED55?

Recording shall commence in the crash protected memory within 250 milliseconds for audio and 500 milliseconds for flight data after power is applied and the start criteria are satisfied. After power interruptions greater than 5 minutes, up to 10 seconds are allowed for flight data sensor initialization and calibration.

This is from Turbofan, one of his specs that fails to prove much of anything.

So data can be missing. There are many examples of missing data in FDRs.

 

[ktesibios]

In the case of flight 587, the relevant rudder information was already safely stored in memory. Nevertheless, the NTSB had to contend with uncertainties in timing due to, as I quoted above, "data latency, data filtering and sampling rate issues".

Regarding the effect of filtering, the accident report says:

The analog signals from the rudder position, aileron right position, aileron left position, elevator position, and horizontal stabilizer position were processed through the airplane’s system data analog converter (SDAC)85 computer before they were sent to the flight data acquisition unit (FDAU)86 as a digital signal. The SDAC computer applied a filter to the data,87 and the FDR recorded the filtered digital value. (Uncertainties in the FDR data associated with data filtering are discussed in section 1.16.2.)
An SDAC bench test was conducted on February 4 and 5, 2002, at Airbus’ facility in Toulouse. One purpose of the test was to define the filtering function and the associated processing delay of the SDAC. The Safety Board and Airbus independently analyzed the results of the test and concluded that the SDAC applied a first-order lag filter with a 0.434-second time constant.*

FWIW, assuming an IIR filter, "first-order lag filter with a 0.434-second time constant." translates to a single-pole low-pass filter with a cutoff frequency of 2.304 radians/sec, or a frequency domain transfer function of F_(s)= 1/(1+s/0.3667). My guess about the purpose of doing this would be that it was to provide cleaner data by filtering out high frequency components which in the time domain would represent impossibly fast rudder motion. If the NTSB wanted to reconstruct the original time-domain rudder position information as it was presented to the filter, there are two ways to do it:

1. Calculate the impulse response corresponding to the frequency-domain transfer function and then deconvolve the recorded rudder data with that impulse response.

2. Transform the recorded rudder data to the frequency domain, then divide the resulting spectrum by the frequency-domain transfer function and inverse transform the result back to the time domain.

Either way, what we have here is an unambiguous example of how working out what happened and exactly when it happened is not necessarily a simple matter of pulling numbers from a list.

You'll also notice that latency and sample rate issues are also mentioned as contributing to the uncertainty of the timing of events recorded in the FDR. "Latency" is a very familiar concept to those of us who work with digital recording and signal-processing systems. It refers to the unavoidable finite time interval between the taking of a sample and the storing of the same in a recording medium. In the digital audio tape systems I used to work with, it was due to the time required for an A/D converter to produce a binary value at its output after being presented with a sample from the S/H stage, followed by the time necessary for error-correction processing, interleaving/deinterleaving and the settling time of the D/A converter. In this case it most likely refers to the time interval between the SDAC taking a sample of an analog variable and the binary result actually being stored in the FDR's memory. That should include conversion time, the time needed to accumulate and assemble all the data making up a frame and the time needed for the data compression applied to conserve storage space.

Again, this is an unambiguous demonstration that even data which has been safely stored in memory can contain significant uncertainty due to the very phenomena which you have been denying exist.

and footnote 84 says:

84 During the initial readout of the FDR, the conversion equation for the rudder pedal parameter was found to be incorrect. Thus, the FDR data had to be examined to obtain reference data to establish the proper equation for the rudder pedal position parameter. In addition, revised equations for the control wheel and control column positions were established based on the FDR data.

OMG! Even if you have the information to decode the data straight from the horse's mouth, you can't count on it being Gospel! They actually had to reverse engineer the encoding to get useful information.

I wonder what the implications would be for PfffT's gaggle of wankers.

 

[celestrin]

Oh, shucks, another arrogant truther ignoring me...

Tell me Turbofan, if NTSB animations are produced automatically from FDR data, there shouldn't be any NTSB animations that were ever wrong or in need of corrections, right? What would you say, if I presented such a case?

Tell me, Turbo, how would it be possible for an automated software animation generator to get the true and magnetic headings mixed up? How could such an automated import mixup rudder data? Yet this is what happened here.
http://www.ntsb.gov/events/2000/aa1420/anim_summary.htm

How does this affect your fantasy? (This has essentially become a rhetorical question, I'm pretty convinced your rabbit has just escaped into an even deeper hole.)

Tell me, Turbo, you do know what the lower plot on the image I'd posted in my last post, shows? It's the difference between pressure altitude and radar altitude. The last 30 some seconds. The plot ends when the FDR data ends, and, as you lot are trying to argue, that's at most 500ms away from the Pentagon. Why did snowygrouch fail to simply draw the line connecting the end of FDR data to the upper plot, showing the ground elevation? Just one simple line. Are you saying he's really that dumb? I'm saying that he didn't like the outcome he got, when he did line up the last radalt position. You see, in this case, your fantasy puts the Pentagon on the top of the hill! I know there was reconstruction work being done to the place at the time, but this is ridiculous, don't you agree?



Of course, snowygrouch is gonna moan how his analysis is not precise or accurate enough to make such conclusions. But his ground elevation plots do reveal a few distinct valleys, which also happen to be in the area west of the Pentagon. The following image shows the Google Earth terrain in the area. I've exaggerated the terrain 3 times, to make it more obvious.



The Pentagon is at the right bottom. The extruded path of constant altitude above ground, follows the path of AA77, as stored in the FDR and retrieved by PffT themselves (the last section of the path, which is missing in the FDR, is simply extrapolated from the last track angle data). The plane would've been flying towards us. Two of the most prominent valleys are easily noticable in the distance. The third one is just a small dip (too coarse resolution, as the plane passed it in one second) and there's the last one at the Pentagon, by the Potomac river.

So, if we take snowygrouch's presentatoin slide as is, at face value, we can correlate those valleys and get the approximate last position of the plane, according to FDR altitude data.



As one can see, Snowygrouch tells us, that the distance between the first two valleys should be about the same as the distance between the second valley and the last position of the plane. Which leads us to this.





More than 4000 feet from the Pentagon. 4000 feet is 5s at the velocity of 800ft/s. That's still 2000 feet from the Pentagon, if one puts a 2000 feet margin of error on the data. PfffT are arguing that the distance from the wall shouldn't be more than 400 feet, and yet, snowy had this data for over a year now. Why hasn't he presented it?

Of course they are still going to huff and puff about the accuracy and margins of error. But Turbo, go ask them why didn't they use more accurate terrain elevation models? This would surely put the margin of error at 2000 feet, if not below, would it not? Guess where would a USGS 30m digital elevation model leave the plane. Guess what Bib Salbamo (good one, Ron ^^d ) said when I asked him the same question about a year ago.

 

[Turbofan]

"Oh shucks...", "Tell me Turbo...", "Why Turbo..."

This thread and the theories presented are quite a joke. I have never
seen so much assumption and grasping in a debate! You guys are throwing
out 'hopes and dreams' looking to find some small insignificant, irrelevant
info to spin on the world!

Magnetic headings: Tell me Celestrin. If the NTSB mixed up the headings,
then how is the plane taking off from the runway, and finding the Pentagon?
Did the headings magically flip mid animation? Haha....carry on.

Anti. You have shown nothing other than a diagram and a basic data path.
Where are the timing charts? Why don't you post those instead of assuming?


I'll tell you another thing, the sensors don't selectively delay and update
old information while other info is current (like DME, pitch, accel, etc.).

Can you imagine what Anti is trying to push here? Old information, stored
2-4 seconds later even though other updates are happening 4 and 8 times
per second (current data).

RAD ALT is updated every second. If it's old info parked in a buffer, the
buffer only has capacity for one value before the next poll time. Sorry to
say, but the four seconds, or two seconds, or whatever you're theory
claims just does hold water.

The new info will over-write the buffer contents on the next update.

Post the timing diagrams for the FDR, or call it a day. Show process speeds,
timing for all bus, buffer and transfer. Until then you have nothing over the
THREE sources I've posted for sensor to CPM <= 500 ms!


Keep reaching, keep hoping to find something ...something to make you believe
your government is not corrupt.

 

[Jonnyclueless]

"
This thread and the theories presented are quite a joke. I have never
seen so much assumption and grasping in a debate! "

Oh the irony there kid. millionas of possibilities, but you seem to know for sure exactly what happened based on how things were 'meant' to work on a theoresitcal level. And in order to do so, you have to dismiss and ignore 99% of the rest of the evidence to do so. Could you be any more pathetic?

In true conspiracy nut fashion, you pick and focus on one single oddity (of which there are many in any event) and pretend that it dismisses everything else. And you know the reason you can't address anything beyond that single anomaly is because you know it is easily dismissed by all the rest of the evidence and that your implications completely fall apart. So it's important for you to never ever veer from your little anomaly because doing so exposes you as a con.

Keep on trying there bucka-roo. Keep spending all your time trying to focus on one detail on an internet forum because you know that it can't get you any attention in the real world. We know that the rest of the world laughs at your beliefs and the only way you can continue to pretend your fantasies are true and your life has validation is by trying to focus on that one thing. One that is based on HUGE assumptions at that.

Remember, real researchers actually try to find the whole story. You kids at PFT aren't researchers, you're charlatins.

 

[Reheat]

You kids at PFT aren't researchers, you're charlatins.

Nah, I think ktesibios' "gaggle of wankers" is best. I don't care who you are that is funny!

 

[gumboot]

As a layman... in this thread I see a bunch of highly intelligent, competent and knowledgeable people providing substantial, measurable, and verifiable arguments against the noisy protestations of an "other" participant.