the learning never stops!

Takeoff and Landing Data "Sense"

Takeoff and Landing Topics

A few years ago I picked up our Gulfstream G450 from maintenance after the FMS had been upgraded. They had also done some engine work so I opted for a rated thrust takeoff on the longest runway. The airplane rotated when I pulled the yoke and the initial climb was okay. But the airplane just didn't have the same feel to it. I searched through the FMS and discovered that our Basic Operating Weight was off by 8,000 lbs. Since our grossweight that day was around 64,000 lbs, our weight was off by 13 percent. Looking back on it, our V1 was off by 7 knots (114 vs. 121) and our balanced field length was hundreds of feet in error (3452 vs. 4142). We typed in our fuel, passengers, and conditions. The FMS churned out the numbers and we believed them.


Photo: Two "A Models"

Click photo for a larger image

Takeoff and Landing Data (TOLD)

These days, we tend to program the performance function of our Flight Management System (FMS), a laptop computer, or our iPads to churn out all the numbers we need to safely takeoff, abort the takeoff, or climb out with an engine failure and subsequent emergency return. Most of us rarely give the numbers a second glance. But this nonchalance has killed before and will likely kill again as we become even more distant from the number crunching.

In the KC-135A, a set of takeoff data could take as much as 15 minutes to compute. The charts required a sharp pencil and even sharper eyes, but mistakes were inevitable. But pilots tended to know what numbers were about right for most situations. See: KC-135A TOLD Example for a painful look at how the numbers shown here were found.

So does that mean I think you should do all this manual number crunching to prevent an input error and to help you get a sense for what numbers are right or wrong? No, not at all. I think there are two steps you can take to accomplish both goals without having to endure the pain of those charts.


Photo: KC-135A Takeoff Data Card, TO 1C-135(K)A-1-1, figure 1A2-8

Click photo for a larger image

Case Study: MK Airlines 1602

In the old water injected KC-135A, takeoff data was critical because we tended to use just about every inch of the runway. These days? There have been a few transport category aircraft lost over the years because of improperly computed takeoff data, perhaps the worst was that of MK Airlines Flight 1602.


Photo: MK Airlines Boeing 747 9G-MKJ, 10 October 2004, 4 days before its crash (courtesy Adrian Pingstone)

Click photo for a larger image

On October 14, 2004, this Boeing 747 took off from Windsor Locks-Bradley International Airport (KBDL) with a load of lawn tractors. It was a short hop up to Halifax International Airport, Nova Scotia, Canada (CYHZ) so their fuel load was small and the total gross weight was 240,000 kg. The aircraft landed, refueled, and took on more cargo (lobsters). The total gross weight was 353,000 kg but the pilots failed to enter the new weight into their laptop computer, only updating the weather and airport. They ended up using a reduced thrust setting. When the aircraft failed to lift off at the computed rotation speed, the pilot pulled back further, resulting in aft fuselage contact with the runway. The aircraft finally became airborne 670 feet beyond the paved surface, but the aft fuselage struck an earthen berm and separated on impact. The rest of the aircraft continued in the air for another 1200 feet before striking the terrain and bursting into flames. All seven on board were killed.


Photo: MK Flight 1602 Takeoff and Landing Performance, AIR A04H0004, figure 6.

Click photo for a larger image

MK Airlines required its crews to verify the computer generated numbers. One method would be to verify the numbers using Volume 2 of the Boeing 747 AFM, which would have been time consuming. Another method, which the accident report seems to indicate was an acceptable means of compliance, was to have a second crewmember use the laptop to verify the first crewmember's work. A more likely method would be for the pilots to simply look at the numbers and agree that they were, "about right."

In the case of the accident airplane, the differences in the numbers should have been apparent. Between 240,000 kg and 353,000 kg the target thrust setting was very close: 1.33 versus 1.30. But the correct V1, Vr, and V2 values were substantially higher: 150 not 123, 161 not 129, and 172 not 137. Fatigue, of course, may have affected each pilot's judgment.

You may argue that the range in speeds for a cargo Boeing 747 are much greater than for a business jet where the largest factor is fuel and is unlikely to render a V-speed off by 30 knots. But if you examine your performance manual, you should find that you too can be placed in an unflyable situation because of improperly computed takeoff data.

Backup Numbers

There are two issues when relying on a computer to produce takeoff and landing data: the inputs could be wrong or the generated outputs could be wrong.


Photo: Takeoff data verification, Eddie's aircraft

Click photo for a larger image

More often than not, when computer-generated takeoff data is in error, it was a case of "garbage in, garbage out." You can increase the odds of accurate data input by having a second person in the loop. I recommend that one pilot program the FMS or laptop computer or whatever system is used to generate takeoff data. Then the other pilot uses another system that isn't affected by the first system, such as another laptop computer or an iPad. That pilot will gather inputs (fuel load, passenger load, cargo weight, weather conditions, runway conditions) without asking for the first pilot's inputs. The numbers are then compared. They should match.

If you are using the same software you also run the risk of having an output error, one caused by the software. Optimally, you will have performance computing application developed by an independent source, but this is rare. That's why you need to develop a sense of what is "about right" for your airplane under any operating condition.

Developing Your TOLD Sense

When it takes five to ten minutes of effort to produce a set of takeoff data, you tend to remember the numbers. Do that daily for a few years, and you will develop a sense of what numbers are about right. But we don't want to do that. Our time is better spent doing other things. But you can, over time, develop a sense of what numbers are about right and what numbers need a closer look.

The old school method of chasing through charts was time consuming and prone to error; but it taught pilots to understand what numbers were "about right" for a variety of conditions. If you look at the KC-135A Critical Engine Failure Speed chart you will see the line bends seven times. Each of those bends is an opportunity for error. One square on the distance line represents as much as 500 feet and one square on the speed can be as much as 2 knots. Each set of data was evaluated to be within 2 knots and 200 feet. Mistakes happened all the time. But it gave us a sense of what was correct and what was in error. One way to reinstill that sense is to chase through the charts even though you have computers to do that for you. But that subtracts time better spent doing other things that also have an impact on safety. There is another way.


Photo: Example Critical Engine Failure Speed computation, TO 1C-135(K)A-1-1, Figure 1A2-20.

Click photo for a larger image

I recommend that instead of simply briefing the numbers, ala "V1 is 115, V2 is 120, and if we have to come back, VREF is . . ." you should always include the basic conditions. For example: "We are taking off using flex power on a cool day, dry runway, and we weigh 60,000 pounds. Our V1 is 121 and V2 is 134. We need just under 5,000 feet of runway."

So what good does this do? I think after ten or twenty takeoffs you will start to develop a sense for how much runway is needed for various conditions. You will soon figure out what are reasonable V-speeds and what are not. You may not be able to detect a 2-knot or 200-foot error, but you will might be able to figure out someone made a large input error.

Letter to Eddie

I get quite a lot of email and every now and then one strikes me as poetry. Here is just such an email.


Several things:

Mistakes have been made (but corrected) it seems during stops for pax pickup and a quick turn home. The FMS won’t update the new fuel load automatically. V speeds will show much lower if not entered manually. After years of flying, the “this doesn’t look right” statement bubble floats up. But not always. The boss has an inert fear of wasting time. This adds to the pressures of getting things done accurately. As you know, a 40 minute turn provides the fertile ground for a mistake. An error. Or not seeing an error. Or expectation bias. Seeing something you expect but didn’t do. Tons of distractions...

But we’re calm, cool and collected. The best way for us to throw down a spike-strip, besides just slowing down, is to SWAP DATABASES and zero out the FMS. This way we are forced to input the data. It literally only takes 2-3 minutes and gives both of us a chance to clear out any cobwebs. It’s a nice fresh start.

This may not work for everyone but it works well for us.


Aviation Investigation Report A04H0004, Reduced Power at Take-off and Collision With Terrain, MK Airlines Limited, Boeing 747-244SF 9G-MKJ, Halifax International Airport, Nova Scotia, 14 October 2004

Gulfstream GVII-G500 Airplane Flight Manual, GAC-AC-GVII-G500-OPS-0001, Jul 20, 2018

Technical Order 1C-135(K)A-1, KC-135A Flight Manual, USAF Series, 10 August 1975

Technical Order 1C-135(K)A-1-1, KC-135A Aircraft Flight Manual Appendix I, Performance Data, 15 June 1966, Change 29, 15 November 1975

Revision: 20181215