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.

— James Albright




There are a couple of ways to react to such a thing. The obvious solution is to vow to read every single line of every takeoff performance page in the FMS prior to every takeoff. That's an easy thing to promise, but are you really going to do that? Me either.

Thinking back on my first large aircraft, the KC-135A, I think I would have detected a 7 knot error in V1. I had a good sense for what the numbers should be. I lost a little of that in the Boeing 707. Once I got to the Boeing 747, I became a slave to whatever machine we used to spit out the numbers. I had lost my takeoff data sense. I want to get it back. Here is my plan.

1 — Takeoff and Landing Data (TOLD)

2 — Case study: MK Airlines 1602

3 — Backup numbers

4 — Developing your TOLD sense

5 — "The books says . . ." (so it must be okay?)

6 — Letter from one of our readers



Takeoff and Landing Data (TOLD)


Two "A Models"

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.


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


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.


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

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.


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

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.


Takeoff data verification

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.


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

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.


"The books says . . ."

(so it must be okay?)

"The book says . . ."

The best way to get a sense of the real world versus the world of spaghetti charts and computerized takeoff and landing data is to fly an old, underpowered airplane on missions that required you to maximize every drop of fuel and inch of runway. I don't recommend it, but that is how I started as a copilot in the KC-135A. We spent a lot of time pouring over charts to insure we could make it off the runway, even if just barely so. For a painful discussion about this: KC-135A TOLD Example.

As an engineer, I had supreme confidence in those numbers. Even if the book said we needed every inch of a runway, I knew with absolute confidence that we could lose an engine at V1 and either takeoff or abort. No sweat.

Then one day we lost an engine and had to rotate in the overrun about 10 to 15 knots below rotation speed. What?


KC-135A takeoff

The math didn't work. The airplane was old, the drag coefficient from the wrinkled skin was higher than the design. The engines didn't put out quite as much thrust as the good folks at Pratt intended. No matter the excuse, I never again looked at the numbers the same way. If the balanced field came out to anywhere near the runway length, it was time to reconsider.

". . . so it must be okay."

As I write this, I just got finished (yesterday) reviewing a friend's autobiography that spends much of its length extolling the poor performance of the stretched MD-80 series. He says they simply put in a plug ahead and aft of the wings and called it good. Then (today), I got this in the inbox:


World Atlantic Airlines MD-83 departing St. Maarten, 28 March 2020, a few feet before the runway end

It is a World Atlantic Airlines MD-83 taking off from St. Maarten (TNCM) two days ago. The caption was, "We paid for the whole runway, we use the whole runway!"


World Atlantic Airlines MD-83 departing St. Maarten, 28 March 2020, a few feet after the runway end

There were more photos after this and the airplane climbed out just fine, leading me to believe it was operating on both engines. That begs the question: if they had lost one of those engines, would they have gone swimming?


A letter from one of our readers

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.


(Source material)

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

Please note: Gulfstream Aerospace Corporation has no affiliation or connection whatsoever with this website, and Gulfstream does not review, endorse, or approve any of the content included on the site. As a result, Gulfstream is not responsible or liable for your use of any materials or information obtained from this site.