It looks like you're using an Ad Blocker.

Please white-list or disable AboveTopSecret.com in your ad-blocking tool.

Thank you.

 

Some features of ATS will be disabled while you continue to use an ad-blocker.

 

New FDR Decode

page: 40
12
<< 37  38  39    41  42  43 >>

log in

join
share:

posted on Nov, 28 2009 @ 06:37 PM
link   
Hey 911files,

Are you John Farmer?

If so, nice to meet cha. If you're not, still nice to meet cha.


Originally posted by 911files
reply to post by tomk52
 


Tomk52, I listened very carefully to your feedback and I think you misunderstand the concept.


Wouldn't be the first time...


Originally posted by 911files
The graph is not a 'scatter shot'. It is a plot of two populations, one based on the upper limit of the terrain elevation within an already defined and known location of the plane (not a haphazard sampling). The other population is the lower.


What info did you use to define your upper & lower profiles?


Originally posted by 911files
Since each location at an instance in time is known based on radar measurements independent of the FDR, actual terrain elevation MUST be between those boundaries. Not even close to your nail impression analogy.


It seems like you're using the ground radar returns to determine the planes position. Correct?
If so, where were those radar?

I'll assume that you've been working this problem for awhile & are familiar with the error bands on your radar range, bearing & elevation numbers.

This whole exercise is, of course, one of "error analysis". With the goal of dropping the error as much as possible.


Originally posted by 911files
My goal was to determine what the populations (upper and lower) were doing over time. The real R. Mackey and others have speculated that air flow and air density at the extreme speeds impacted the accuracy of the PA. I have no opinion on that hypothesis except that it seems qute reasonable. If I understand your hypothesis, the PA is 'lagging' in reference to time. Same deal, I don't know enough about the system to have an opinion, but sounds like a reasonable hypothesis to me as well. Seems to me both would produce similar results.


It does not seem to me that the PA lags very much at all. I would have expected that. But when I initially looked at the double differentiated height (giving me vertical acceleration) and compared it to the "normalized acceleration" (a - 1) taken from the accelerometers, it seemed that the differentiated PA values LED the accelerometer numbers by about 1 second. This was very surprising. It was also an artifact of Warren's "one data point per line" spreadsheet. Once I replaced the first data point with an average of properly indexed 1 second data points, then the data skew disappeared.

The fact that ground compressibility factors could well offset the static pressure port readings seems to me a no-brainer. Anything that changes the flow of air around the body of the plane IS, with zero doubt, going to change the accuracy of the static pressure reading. It is possible that a Computational Fluid Dynamics model of the plane flying at 100' or less could tell you what would happen to the static reading. But a better answer would be either a wind tunnel test or convincing someone to let you fly their 757 at 480 knots, down to a height of about 15' AGL. Good luck with that.

[End Part 1]



posted on Nov, 28 2009 @ 06:37 PM
link   
[Part 2]


Originally posted by 911files
I am not using my 'eye' or anything else to reach my conclusion. That is why you see a calculated linear fit for both populations. Those fit lines are the only thing I am concerned with. The tell me that the difference between the raw PA and calculated elevation (RA + terrain elevation) decreases over the final 18 seconds by ~100 feet. That is my interest, what the data is doing, not why it is doing it. That way I can make some reasonable data based predictions to improve my correlation. If it happens to support yours or Mackey's hypothesis is for others to debate.


Both the real Ryan Mackey & I have exactly the same allegiance: the truth. No matter what. Both of us have had enough experience & successes that it is not a problem to admit that we've been wrong about something.

Being rigorous & demanding of you is NOT a personal attack. It is helping you do the best work that you possibly can.


Originally posted by 911files
My purpose was to improve my time correlation model and resultant positional data. That chart helped me refine my lat/long offsets and gave me a much better fit with the radar data once completed. If you don't find it useful, then I apologize.


No reason at all to apologize to anyone. You're doing the work for yourself, your own understanding, etc. And you'll at some point share it with the world. One suggestion I'll make. Do the same thing that the professionals do: BEFORE you release it, show it to several of the most competent people that you know. Get their feedback & listen carefully. The person that points out a mistake BEFORE you publish your work is your best friend in the whole world. Also, whenever possible, work in collaboration with others. Your team provides sanity checks that very few people can provide on their own.


Originally posted by 911files
But I would suggest that instead of nit-picking you come up with a better model to understand what you are asserting, and I certainly would appreciate any data driven assistance. For now though, I don't think the model can be refined much further. Yet I still anxiously await what censura comes up with.


I'm really not familiar with your model. The comments that I made regarding interpreting ground data are generic, and apply to anyone trying to do this. I'll try to describe what I mean in a follow up post.

TomK



posted on Nov, 28 2009 @ 09:34 PM
link   

Originally posted by tomk52
Also, whenever possible, work in collaboration with others.


If you only knew



posted on Nov, 29 2009 @ 01:18 AM
link   

Originally posted by cesura
You said you/yours had buried grandmothers who knew
a general form for linear equations in two dimensions.
I apologize for assuming one of those grandmothers was
your own.

Will

Has it occurred to you yet that I might have more than 1 "grandmother?"

Do you enjoy "probing" into my deceased ancestors' history, or are you writing a book?

Edit: P.S.- I think you are [straw-man] MIS-QUOTING me there, Giggles]

[edit on 29-11-2009 by rhunter]



posted on Nov, 29 2009 @ 01:57 AM
link   
Sorry for joining this thing late. I'm kinda jumping in right in the middle of things so I apologize in advance if this has been covered already.


Originally posted by turbofan


No , sorry TomK...You're wrong.

The only error I made was mistaking the "A" for a "V" in the diagram.


Yeah because the ASI and the VSI are the same gauge, so it's just a spelling mistake....yeahh...thats it!



I don't know we're you're going with this, other than I mixed up a letter.
It makes no difference as I've already described how the VSI works.


Yeah it makes no difference. You can actually swap an ASI for a VSI...its no sweat, right Turbofan? Oh except that you have been shown to be wrong, even by your own diagram. The standby ASI/ALT steam gauges are independent of the ADC and there is no Standby VSI. You would be correct to say that the VSI's input comes from the ADC(as well as accelerometers from the IRU that reduce the inherent pneumatic lag in the static system). It's been awhile since I changed a VSI on a 757/767, but I'm pretty sure there is neither a pitot, nor a static connection; its a signal from the ADC and IRU.

Don't know where we are going with this other than the so called PA discrepancy. It's really no mystery, in fact, the reason we now have an Instantaneous VSI is because of pneumatic lag. Then there is the fact that the ADC of a 757 isn't looking for a high delta-p between pitot and static(ie high speed low altitude, or vice versa); so we can safely say that the flight profile before impact was beyond the 757 air data certification range. I have other reasons for believing the PA data to be inaccurate from my own personal experience testing these systems. I'll elaborate further if the discussion meanders back in that direction.



Errors by TomK in this thread caught by Turbofan


- Thinking PA was measured by an aneroid type altimeter. In fact,
it's measure by an air data computer using an electric sensor.


Assuming you didn't mangle what he actually said - you're both wrong. The altimeter, of course, doesn't measure anything; it displays a measurement. And its not measured by an electric sensor. The only thing electric in a static port is the heater. There is no such thing as electric altimetry/airspeed sensor(at least as far as Boeing airliners are concerned), and please don't tell me the ADC is a sensor.



- Thinking "absolute pressure sensor" was indicating an absolute value/reading of PA, when in fact it was clear I was talking about the "absolute pressure sensor".


What is an absolute pressure sensor? Can we stick to standard aviation verbage, please? If you mean, ambient pressure sensor, that would be a static port. So what exactly did he get wrong?


[edit on 29-11-2009 by 767doctor]

[edit on 29-11-2009 by 767doctor]



posted on Nov, 29 2009 @ 02:04 AM
link   

Originally posted by 767doctor
Sorry for joining this thing late. I'm kinda jumping in right in the middle of things so I apologize in advance if this has been covered already.


Not late at all, we just had a slight distraction with a door, but this is perhaps the major issue at hand, the seeming condtradiction between PA and RA. Your input would be greatly appreciated I'm sure.



posted on Nov, 29 2009 @ 02:13 AM
link   
Hi "apathoid."

Welcome to the thread.


[edit on 29-11-2009 by rhunter]



posted on Nov, 29 2009 @ 02:20 AM
link   
reply to post by 911files
 



Yeah, you pretty much buried the cockpit door issue, at least, for reasonable folks. As for the "PA is too high for the lightpoles" argument, I had a few ideas that have probably been brought up before. If we could find a VSI parameter(I didn't find it), couldn't we compare the frame to frame differences between it and the PA - which would show that PA is lagging, the higher the vertical speed. The same could be done with vertical G's, but maybe less precisely.



posted on Nov, 29 2009 @ 02:34 AM
link   

Originally posted by rhunter
Hi "apathoid."

Welcome to the thread.


[edit on 29-11-2009 by rhunter]


Thanks. I'll mostly be lurking here, it seems there are some very knowledgeable posters here. But, I'll add my 0.02 every now and again.



posted on Nov, 29 2009 @ 04:01 AM
link   
reply to post by 767doctor
 


There is 'VERT SPEED SELECTED' ft/min in the recorded parameters (word 124) but I'm not certain whether that's a live VSI reading or an input to the autopilot. It hasn't yet been included in any decodes I've seen to date.



posted on Nov, 29 2009 @ 04:36 AM
link   
For anyone interested, here is a csv file with the entire 42 hours for the FLT DECK DOOR parameter. It is sampled once every 4 seconds. I could sure use some help finding that one OPEN value. I can't seem to find it.

FLT DECK DOOR - 42 hours worth

I don't know why I did not do it earlier. I guess I just enjoyed listening to the P4T boys squirm.



posted on Nov, 29 2009 @ 05:46 AM
link   
For anyone who needs documentation that the FDR system was updated due to a change in regulation in 1997, a regulation which also caused the revision to the data frame layout provided by Turbofan, please see here.

pilotsfor911truth.org...


n late 1997 the U.S. Federal Aviation Administration (FAA) adopted a change requiring an increase in the number of recorded signals for flight data recorders (FDR). This rule change will affect many airplanes that operate under FAA rules, including all airplanes registered in the United States and those in other countries where regulatory authorities use the FAA rules as their own. Boeing is prepared to help operators meet the requirements of the rule change by its effective date, which varies according to each airplane's date of manufacture.



Boeing models 707, 727, 737-100/-200/-300/-400/-500, 757, 767, 747-100/-200/-300/-400, 777-200/-300, DC-8, DC-9, DC-10, MD-11, MD-80, and MD-90 will require retrofit activity. This may involve the addition of new sensors and wiring plus installation of a DFDAU, software, or both because of a new FDR frame. The details of the Boeing plan to support the airplanes listed below are discussed in "Rule Change Support Plan".


For those who would like to see the previous 11 flights, all of which were relatively short legs according to Warren, being discussed by real pilots who are verified, please see here.

pilotsfor911truth.org...

For those who claim the cockpit door sensor was not required equipment (ie. a "no-go" item on the 757), please see apathoid/767Doctor reply here.

forums.randi.org...



...a bad cockpit door switch, even pre-9/11, was likely a "no-go" item for flight. Its sole purpose is NOT to provide a record for the FDR, its to warn the pilots if the door is ajar by providing an amber message on the engine display.


For those who claim FLT DECK DOOR was an available parameter on the FDR, but not sensing anything, Please see Turbofan's post here,

www.abovetopsecret.com...

If the parameter port were grounded due to inoperative system. it would not be labeled as FLT DECK DOOR. It would be labeled as "spare" and we wouldn't even be able to see it as observed in the UA93 data (there is no FLT DECK DOOR parameter on UA93).

@767Doctor/apathoid,


...so we can safely say that the flight profile before impact was beyond the 757 air data certification range.


How can the pitot-static system be operating "beyond its certification range" when the aircraft data shows only .70M-.72M and the aircraft is certified for .86M? Do you also believe such mach numbers are above Mcrit for a 757 as does Ryan Mackey?

This one post takes care of every single excuse made by those who wish to hold onto their support of the govt story.



posted on Nov, 29 2009 @ 05:53 AM
link   

Originally posted by Pilgrum
reply to post by 767doctor
 


There is 'VERT SPEED SELECTED' ft/min in the recorded parameters (word 124) but I'm not certain whether that's a live VSI reading or an input to the autopilot. It hasn't yet been included in any decodes I've seen to date.



It's for the autopilot. I believe the parameter you're looking for is VVI, it's not there. It's also not a required FDR parameter. If installed, it would use one of the "spare" ports as Turbofan explained and then you would see it. The reason some airlines don't install this parameter and the FAA does not require it, is because you can calculate your Vertical Velocity from the PA.



posted on Nov, 29 2009 @ 06:01 AM
link   
reply to post by R_Mackey
 


I am still confused. If the FAA required the Flt Deck Door parameter to be recorded why didn't UA 93 have one ?



posted on Nov, 29 2009 @ 06:07 AM
link   

Originally posted by Alfie1
reply to post by R_Mackey
 


I am still confused. If the FAA required the Flt Deck Door parameter to be recorded why didn't UA 93 have one ?



The FAA does not require the FLT DECK DOOR parameter on the FDR. The FAA rule change in 1997 required 88 parameters to be completed by Aug 2001. As you can see, AA77 data has many more parameters being measured than what is required. The FAA requirement is a MINIMUM requirement.

Since the Cockpit door sensors are installed on the aircraft, it appears American Airlines hooked it up to a spare port on the FDAU. United Airlines did not.

Please do not confuse this with the MEL. If the physical system is installed, it is required equipment (or can be deferred as per the MEL). But according to apathoid/767Doctor, it's most likely a "no-go" item if the system failed.

[edit on 29-11-2009 by R_Mackey]



posted on Nov, 29 2009 @ 06:07 AM
link   

Originally posted by Alfie1
reply to post by R_Mackey
 


I am still confused. If the FAA required the Flt Deck Door parameter to be recorded why didn't UA 93 have one ?


That is the intent Alfie. They put up a bunch of technobabble and when it is all said and done, the fact remains that in 42 hours of recorded operation, not ONE valid OPEN value for this parameter. That defy's reality.

In all of the technobabble, there is no evidence that the parameter was added or upgraded to the 757-3 A2 frame, or that this parameter was part of any required upgrades. Just more smoke and mirrors.



posted on Nov, 29 2009 @ 06:10 AM
link   

Originally posted by R_Mackey
Since the Cockpit door sensors are installed on the aircraft, it appears American Airlines hooked it up to a spare port on the FDAU.


Show us the evidence of that, not all of this technobabble.



posted on Nov, 29 2009 @ 06:33 AM
link   

Originally posted by R_Mackey

Originally posted by Alfie1
reply to post by R_Mackey
 


I am still confused. If the FAA required the Flt Deck Door parameter to be recorded why didn't UA 93 have one ?



The FAA does not require the FLT DECK DOOR parameter on the FDR. The FAA rule change in 1997 required 88 parameters to be completed by Aug 2001. As you can see, AA77 data has many more parameters being measured than what is required. The FAA requirement is a MINIMUM requirement.

Since the Cockpit door sensors are installed on the aircraft, it appears American Airlines hooked it up to a spare port on the FDAU. United Airlines did not.

Please do not confuse this with the MEL. If the physical system is installed, it is required equipment (or can be deferred as per the MEL). But according to apathoid/767Doctor, it's most likely a "no-go" item if the system failed.

[edit on 29-11-2009 by R_Mackey]


Thank you for that. My understanding now is that a Flt Deck Door sensor, warning the pilot by a display that the door may not be shut properly, is a completely seperate issue from transmitting that information to a FDR.

I can see that the pilot may well want to know that the door is properly secure but I would have thought that pre-911 perhaps it would not be considered a great priority for recording in the FDR.

Do you have anything to suggest that the door sensors were hooked up to a spare port on the FDAU please ?



posted on Nov, 29 2009 @ 06:45 AM
link   

Originally posted by Alfie1
Do you have anything to suggest that the door sensors were hooked up to a spare port on the FDAU please ?


Alfie,

The fact that it is listed as a parameter and you can see it, is proof it was "hooked up". If it wasn't hooked up, you wouldn't see it, as in the UA93 data.

If it wasn't hooked up, the port would be labeled as a spare and grounded. As explained by Turbofan.

Some then made the excuse that Turbofan was using a 1997 revision of the data frame layout and that it didn't apply since the aircraft was manufactured in 1991. What these people fail to realize is that regulations change, and so do the aircraft which are under such regulation. I provided documentation for that as well above.

Hope this helps.



posted on Nov, 29 2009 @ 07:57 AM
link   
reply to post by 767doctor
 


Oh, we have another "I.D. ten Tee" amongst us? I'll forgive you
for not reading the entire conversation before making a fool of yourself
this time.

If you go back through the discussion you will note the following:

- When I'm speaking of Vertical Speedl I already know that it is based on
readings from the static port.

- I already know that VSI is fed by the air data computer [ADC] which
is what produces the FDR data.

My only error was looking at the diagram on a laptop with a screen resolution
that made it appear the second STBY instrument was a VSI.

This has absolutely no bearing on the discussion because we are looking
at PA values to prove the aircraft was too high to hit light poles and the
Pentagon.

I...read that I", was the one who suggested to extract VSI from the
last four seconds of the FDR to confirm Pressure Altitude.

So whether, or not I was mistaken about the letter, or the instrumet...
it doesn't mean squat because on page 32 (?) I have already told you,
and TomK that the VSI reads from the static port and records the rate
of change in altitude (meaning ascent/descent rate).



[edit on 29-11-2009 by turbofan]

[edit on 29-11-2009 by turbofan]



new topics

top topics



 
12
<< 37  38  39    41  42  43 >>

log in

join