Would you like a lesson on Pressure Altitude?
I can't speak for beachnut, but I like to learn. Give me a lesson on PA. Go ahead the floor is yours....
Would you like a lesson on Pressure Altitude?
The FDR has 40 feet; the animation uses an offset to show what the pilots see on the Altimeter based on 40 FEET. NO MISMATCH 40 feet PA is 300 feet on the altimeter as the pilots saw with the proper altimeter setting in the little window on the altimeter, the pilot sets it! It is even in the FDR, this can be automated for the animation.Would you like a lesson on Pressure Altitude? Maybe you and I can calculate the elevation at runway 30 and we can figure out which file is reporting the correct value.
From there, we can hypothesize about how two files from the same source contain different values for the same point in time.
I can clearly see the roll back in the animation on climb. Unforturnately, this does not happen on descent through 18,000 feet. Once again, there is an error at this point in the data.
Me program in FORTRAN, Ada, Pascal, assembly, BASIC, and more so I could automate the animation altimeter to show the altimeter setting, and a corrected PA based on what the pilots had in the little window. Me talk like an engineer; oop me m 1. Do I need to use the real terms for the little window, baro something or something. damn ... kab
I can't speak for beachnut, but I like to learn. Give me a lesson on PA. Go ahead the floor is yours....
no sir, you are incorrect.
If that were true, then the altitude values at 29.92 would also need correction.
In fact, once the calibration of 29.92 is entered the altitudes match.
So there is an error while the aircraft is sitting on the runway, all the way up to 18,000 feet.
Then, on descent another error as the pressure altimeter does not adjust once below 18,000 feet when local pressure is entered.
I hadn't clicked on the "ignore" button yet, so I'll add this.Gravy, thank you for your information. I'm more interested in the factual government data that is currently conflicting.
As a computer/software guy, this mismatch in data highly concerns me and is difficult to explain from a programming point of view.
The FDR does show 40 feet; correct with local altimeter setting the value is 300 feet. The animation used a correct value for local altimeter to 18000 feet.
Reality is trying to stare you in the face, but you keep turning away and brooding over a few details of an animation that was never used for any official purpose.
thank you for your comments Mark. Unfortunately, software doesn't work by changing CSV values whether it's an official copy or not. The coding which exports these CSV data do not care whether the animation was meant for official purposes.
If you like, we can start another thread on basic programming code which will show that no matter what the colour of the leaves may be...the output never changes. Send me a PM if you' re interested.
Welcome to the forum, Scott. Whoever put together the animation at the NTSB failed to account for magnetic deviation. When that adjustment is made the animation matches the actual flight path. The NTSB said the animation was a working copy" which was "never used for an official purpose."
No offense sir, but you are clearly showing your weakness on how this software operates.
The software does not arbitrarily single out certain frames of data and convert them. If you expect me to believe the correction was applied to only a select set of frames and then magically adjusted properly for 29.92, you are sadly mistaken.
Once again, call up a software company or talk to a computer programmer. Alternatively, list the software which you claim corrects only certain frames and leaves others alone.
Reheat, I will gladly start a new thread to discuss Pressure Altitude. I will send you a PM with a link shortly. We can continue tomorrow as it's 2:00 AM here.
Do you understand the amount of data that would need to be input from the technician manually?
What flight software package requires this manual manipulation?
"The Person"? The file is loaded into the software, there is no human input required.
Aside from magnetic variation, there are a host of other issues to consider. Are any of you sotfware/programming savvy by chance? These replies are not making sense.
A rational explanation is that no one had brought the error to their attention by the time the FOIA response was made.Im confused. Why doesn't the NTSB disclose such a blatant error on their part?
The NTSB has set precedent in correcting their errors on such an issue. Google American 1420 in Little Rock. The NTSB corrected just a small 3 deg error in their animation. ..
Also, Scott, the reason the csv and animation don't match with respect to the climb is due to pressure altitude vs. true altitude. However, it is interesting to note that they do match on the descent through 18,000 all the way to end of animation. Why did the NTSB remove the atimeter setting data on the descent in the animation? To make the aircraft appear lower than true altitude? If this data was not omitted, the animation altimeter would read almost 300 feet higher, as it does at departure at IAD.

Didn't the NTSB get the big red "Easy" buttons we sent from NWO HQ in 2000?Wait, I thought these animations were infallable?
A rational explanation is that no one had brought the error to their attention by the time the FOIA response was made.
jtribby, did the NTSB explain the cause of that 3-degree animation error? Also, a link would be helpful since you're familiar with the issue.
The letter you reference is dated March 22, 2007. If the NTSB couldn't catch their own error since 2002 (dates of the original csv file), they were notified of such discrepencies almost 6 months prior to the letter you reference. The NTSB has never made any mention of a "failure to account for magnetic deviation" and they are aware of such a discrepency in their "working copy" which they state they want everything to be as accurate as possible.
The only people I have seen make the claim of a magetic deivation are people here. The NTSB makes no such claim while admitting to other errors. And as show above, they were aware of the flight path discrepencies.
jtribby, did the NTSB explain the cause of that 3-degree animation error? Also, a link would be helpful since you're familiar with the issue.
Animation of Flight 1420 landing [2.2M]
[SIZE=-1][Windows Media Format - requires Media Player][/SIZE]
[SIZE=+1]Summary:[/SIZE]
This animation shows the last minute of flight for American Airlines Flight 1420, which crashed while landing at Little Rock, Arkansas on June 1, 1999. The reconstruction uses data retrieved from the Digital Flight Data Recorder and excerpts from the Cockpit Voice Recorder transcript. The animation starts with the airplane at a barometric altitude of 664 feet, an airspeed of 154 knots, a Localizer beam deviation of 0.4 DOTS to the right and 0.6 DOTS above the Glide Slope. The animation shows the airplane touching down to the right of the runway centerline and continuing to track to the right nearly reaching the right edge of the runway before changing direction to left. The remaining landing roll shows the airplane passing through the runway centerline and eventually departing the left edge of the runway just before reaching the end of the runway.
The instruments displayed represent the following (from upper right to lower left): Airspeed, Altitude, Artificial Horizon, Heading with Localizer and Glideslope Deviation, Rudder Position, Right inboard spoiler position, Derived control wheel position, Left outboard spoiler position, Thrust reverser position (unlocked or deployed), and Engine Pressure Ratio.
Correction: The aircraft motion depicted in the animation is accurate. However, heading data values and rudder pointers are corrected in the updated version shown at the Board Meeting October 23, 2001.