technophobe
[‘tekne fob’]
NOUN
A person who fears, dislikes or avoids new technology.

Yes, I am a technophobe in the strictest sense of the definition, with an emphasis on the word “new.” I don’t trust anything that hasn’t been proven.

Of course, it wasn’t always that way. I embraced computers early on. As an engineering student in 1974, my interaction with computers was via punch cards, and you counted lines of codes by the thickness of your card deck.

In 1983, I wrote a program for my U.S. Air Force Boeing 707 squadron to automate the chore of computing navigation and fuel logs and I thought that was great until we discovered an error in one of my lines of code. My mistake impacted all four of our squadron’s airplanes. In 2004, another software error in an air traffic control computer impacted 800 airplanes.

As aircraft become more and more dependent on computers, the result of a “software glitch” becomes harder and harder to predict. If an airplane is completely airworthy when flying on one side of a line of longitude, how could an imaginary line in space prevent it from flying according to specs on the other? Or how about another airplane whose electrical system now has a calendar-based limitation? Examining a few examples where these glitches were thought to be unpredictable can help us better prepare ourselves for what we cannot possibly foresee.

Going Digital for the First Time

In 1982, I was a copilot flying U.S. Air Force Boeing 707s (EC-135Js) with only one thing in the cockpit that could be remotely called a computer, and that was the flight director. A mission always started the day before with the navigator pulling out a paper chart, a plotter and dividers. After a few hours he would have a navigation log. Then I would take that log and a book of charts and add fuel computations. I would hand all of that to the aircraft commander, who would pick up the phone and order a fuel load for the next day’s mission. This ritual took about 4 hr. All that changed the following year when the squadron got its first desktop computer, an IBM PC 5150.

The original IBM PC was an 8-bit computer. (More on that later.) Using what I had learned in college by programming mainframe computers, I wrote a program to automate the chore of preparing navigation and fuel logs. After that, our squadron started churning out navigation logs in minutes instead of hours.

Before I got the program running, I upgraded to aircraft commander and was assigned to fly a mission our squadron only got once every few years and it required some unusual flight planning. We were required to fly just a couple of hundred feet above the water and head right at Russian spy ships decked out to look like fishing trawlers. These ships became known as AGIs, since the U.S. Navy classified them as “Auxiliary, General Intelligence.” We were told they were armed and that it was best for us to fly as fast as possible, as low as possible. So, that’s what we did. When I wrote the fuel-planning software, I made sure it included the airplane’s entire operating envelope. Job done.

A few years later I was an examiner pilot and none of our copilots could remember the days of having to chase through charts to compute fuel burns. They just plugged the navigation data into the software and out came the fuel log. In fact, that was true of many of our aircraft commanders. They just looked at the top line of the fuel log and ordered whatever it said.

However, when I saw that an “AGI Hunter” trip came up, I eagerly added myself to the schedule to administer a route check. The evening before the flight, I checked the crew’s paperwork and thought the fuel load was a little light. Skimming each leg of the flight plan, I saw typical fuel burns of, say, “-5,500 lb.” for a shorter leg and upward of “-20,000” for a long one, meaning that was how much fuel was “subtracted” from the tanks. When I got to the low-altitude, high-speed leg, the fuel burn was “+10,300 lb.” In other words, they ended that leg with more gas than when they started. Considerably more. I called the logistics branch and added 20,000 lb. to the fuel order.

That night I examined my computer code, written many years before, and found the error. I was missing a multiplier for the legs flown at high speeds below 1,000 ft. MSL. Nobody had ever flight-planned that since I released the program and my oversight went unnoticed.

I briefed the crew about this before the flight and they were obviously concerned. Had they busted the trip before it left the ground? I joked that I would have to bust myself since I wrote the program. But I also gave them a few techniques to make sure they could catch this kind of error in the future.

Technophobe Technique. Try to develop an idea of how much fuel your airplane burns in various phases of flight so you can do some quick math to check the computer’s prediction. I keep a few numbers in mind for my Gulfstream G500 loaded with enough gas to make it from Boston to London at a cruise altitude of 41,000 ft. (to keep both pilots off oxygen). I know we can usually make it to altitude using just over 2,000 lb. of fuel. We can then cruise at Mach 0.90 burning around 3,000 lb. every hour thereafter. If we wanted to stretch it, pulling back to Mach 0.85 saves us about 500 lb./hr. Let’s say we want to know how much gas is needed to fly 5 hr. at the higher speed. I would say 2,000 lb. to climb, then 3,000 lb. each for hour. That comes to 17,000 lb. before alternate, reserve and other planning numbers.

Going Digital Means Going Binary

Of course, I was an amateur computer programmer using an 8-bit computer, which seems archaic by today’s standard. But was does “8 bit” mean? We know it has something to do with the ones and zeroes of binary math, but what does that mean? It is all about counting.

Most of us humans have an instinctive understanding of “Base 10,” a numbering system based on the total number of fingers on two hands. We have concocted 10 symbols (0, 1, 2, 3, 4, 5, 6, 7, 8 and 9) to represent varying numbers of things, including a symbol that represents no number of things. When it comes time for more than 9, we append a symbol to the left and that means that number of things times 10. For example, 29 means two times 10 plus 9 more. That continues as you add digits to the left with even greater multipliers. OK, we all get that. This system is very efficient, in that you can represent a very large number of things with a small number of symbols. We could say we have 1,347 of something, or we could draw a hash mark that many times. Base 10 is very convenient.

But computers don’t have 10 fingers, so Base 10 is not how they “think.” What a computer does have are lots and lots of switches. That’s all a transistor is, after all, an electronic switch.

A simple transistor has three wires, using one wire to signal a “yes” or a “no” to allow current to travel between the other two wires. It is a basic switch that is either on or off; or we can say either 1 or 0.

Binary is “Base 2,” which also has symbols for counting. They are “0” and “1” and operate much the same way Base 10 operates, but not as conveniently. That 0 and 1 are what constitute a “bit,” which stands for “binary digit.” Let’s count from zero to four using bits: 0, 1, 10, 11, and 100. This is cumbersome, but it is the language of a computer processor.

If you put eight of these bits together, you end up with a byte. Here is the number 255:

11111111

That’s 8 1s, or Base 8. If you wanted to convert this to decimal, you take each number, starting from the right, and use that as the exponent to the number 2 (because we are binary) and add everything together. The tricky part is that we have to reverse it and start with zero. So 11111111 comes to 2⁰ + 2¹ + 2² + 2³ + 2⁴ + 2⁵ + 2⁶ + 2⁷ = 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 = 255. 

This is significant because that means eight switches (on or off) can be combined to represent 256 numbers. (Remember to add the initial zero.) We have a standard called ASCII (American Standard Code for Information Interchange) that converts those 256 possible values into letters, numbers and other symbols. Let’s say you wanted to represent the uppercase letter “A” for example.

The binary answer is a series of 8 bits: 0 1 0 0 0 0 0 1. You can convert this to the ASCII decimal by converting the 1s, reading from right to left. The first 1 is in the “0” position, so that comes to 2⁶ = 1. The seventh 1 is in the 6th position, so that comes to 26 = 64. So, A is represented by 1 + 64 = 65.

Let’s try something a little longer, the number 4,294,967,295:

11111111111111111111111111111111

That’s 32 1s, or 32 bit. If you own any “legacy” computers chances are they are 8-, 16- or 32-bit computers. You may even be flying an airplane using 32-bit (or earlier) computers. Depending on what your airplane is doing with those computers, this could be important.

An Air Traffic Control Center’s Reboot

On Sept. 14, 2004, as many as 800 commercial airline flights bound for Southern California were diverted and departures were delayed for more than 3 hr. after radio and radar equipment failed at the Los Angeles Air Route Traffic Control Center in Palmdale, California. Radios went dead and radar screens went blank, all without warning. Controllers used their personal cellphones to contact other centers so the latter could contact and sort out the airborne traffic. There were no accidents, but at least 10 aircraft had what is euphemistically called a “loss of separation.” News reports from the time said: “Exactly what went wrong was not immediately determined.”

There isn’t much official about the incident, but it seems it was due to a timekeeping error with the center’s computers, which tracked the passage of time by starting with the number 4,294,967,295 and counting down once a millisecond. That number, you may recall, is what 32 bits comes to in Base 10.

Which meant that it would take 49 days, 17 hr., 2 min. and 47.295 sec. to reach zero. Can time go negative? Perhaps, but apparently not in this computer. Usually, the machine would be restarted before that happened, and the countdown would begin again from 4,294,967,295. I have read that some people were aware of the potential issue, so it was policy to restart the system at least every 30 days. But in this particular cycle, the computer ran for 50 days without a restart, hit zero, and shut itself down.

If you ever had a 32-bit computer that you allowed to go into “sleep mode” regularly rather than have to wait for the full boot-up process the next day, you may have noticed the computer crashed on you now and then. Perhaps it was 49 days since its last crash. Now you know why.

The fix would be to rewrite the code so that instead of shutting down, it simply restarted the count on its own. Modern computers these days are using 64-bit processors, which, if instructed to count backward from 2⁶⁴ in milliseconds, would end up at zero in 584.9 million years. So, we can worry about this later.

Technophobe Technique. In the days following Sept. 11, 2001, a NOTAM was issued in the U.S. requiring crews to monitor emergency frequency 121.5 MHz, but that mandate was allowed to expire. In some parts of the world there are backup air traffic control frequencies. Well, guess what? There is a backup frequency here, too, and you should make use of it: 121.5 MHz.

The F-22 and the International Date Line

If you’ve ever flown an airplane that came right out of the factory you will probably have experienced what the U.S. Navy calls the shakedown cruise, an initial outing to shake out all the glitches. But in an airplane, the shakedown lasts several months. If you are flying a brand-new aircraft type, it could last years.

At the time of its introduction, the Lockheed Martin F-22 Raptor was the pride and joy of the U.S. Air Force. At $360 million per aircraft it was not cheap, but it represented the cutting edge in technology. In February 2007, a flight of six Raptors were scheduled to make their first deployment from Hawaii to Japan, on the wing of a refueling tanker.

All was going smoothly until they crossed the International Date Line, when the computers on all six fighters stopped working. The pilots were left without navigation, communications or fuel management. Attempts to restart the systems proved unsuccessful. Fortunately, their fly-by-wire systems were still working, they were able to visually signal the tanker to turn around, and they had enough fuel to make it back to Hawaii. The cause was said to be a “computer glitch in the million lines of code.” The Air Force never confirmed what went wrong, only that it was fixed within 48 hr.

Technophobe Technique. Be mindful of an aircraft’s limitations and history. If it hasn’t been done before, realize you are a de facto test pilot and need to develop an exit strategy for those periods where you are quite literally flying into the unknown. A better plan would be to leave the experimental flying to the experimental test pilots.

The Boeing 787 and Dreams of Simpler Systems

In 2015, the FAA issued an Airworthiness Directive that, at first reading, seemed more of a prank than anything else. When have you ever heard of an aircraft electrical system with a calendar-based limitation? Well, here you go:

“This AD was prompted by the determination that a Model 787 airplane that has been powered continuously for 248 days can lose all alternating current (AC) electrical power due to the generator control units (GCUs) simultaneously going into failsafe mode. This condition is caused by a software counter internal to the GCUs that will overflow after 248 days of continuous power. We are issuing this AD to prevent loss of all AC electrical power, which could result in loss of control of the airplane.”

I read that AD from cover to cover for signs it was a joke. Why does a GCU care about the 248th day any more than the 247th? There were a number of “tech blogs” at the time that hypothesized there was a timer in the GCU that counted in 100ths of a second and that 100(2³¹) = 214,748,364,800 sec., which when divided by the number of seconds in a day equals 248 days and therefore the computer in the GCU couldn’t multiply beyond 2³¹ for some reason.

But that makes no sense because 2³¹  means nothing in the computer world. But what if you dedicate the first bit of that 32-bit data register to a plus or minus sign? That would leave you with enough bits left over for 248 days, 13 hr., 13 min. and 56.47 sec. counting in 100ths of a second. The fix has been to require the airplane to be rebooted more often.

Technophobe Technique. As the aircraft I’ve flown have grown with complexity so has the “cold boot” process. I have noticed that if the boot-up process does not go the same way it usually does, chances are something is not going to work correctly later in the flight. I think you should carefully watch and record what a normal boot-up looks like.

A cellphone video of the cockpit during a normal boot gives you a quick reference for when the boot-up just does not seem right. It may save you time in the long run to reboot as soon as you see the cold boot is not progressing normally. After 10 years with the Gulfstream G450 we got pretty good at predicting this. If you are going to have to reboot anyway, it is better to get it over with early rather than have to do almost the entire preflight twice. We are now flying a new aircraft, and we are still learning. And still recording.

What Is a Line of Code?

You often hear manufacturers beg forgiveness for technical glitches by saying it was impossible to predict because of the millions of lines of code in the aircraft’s computer systems. What does that mean? Consider a student computer programmer’s first program, the so-called “Hello World Program” written in a computer language that is so basic, it is called BASIC (Beginner’s All-purpose Symbolic Instruction Code).

10 PRINT “Hello World!”

That’s one line of code. Now let’s make it just a little more complicated:

10 PRINT “Hello World!”
20 GOTO 10

Now you have two lines of code and there is an error. The error is called an “endless loop” because the program will just keep printing “Hello World!” over and over without end.

It was an easy error to spot. The F-22 Raptor’s error was said to be somewhere amongst 2 million lines of code. The error in my flight-planning software for the Boeing 707 was buried in just over 5,000 lines of code and the only way I found the glitch was to have someone actually attempt to fly the specific condition.

An Example of a Serious Line of Code Error

The Gulfstream GV was a game-changer in business aviation, offering unparalleled speed, range and efficiency. In 2004, the model was updated with the Gulfstream G550, the same basic airplane with a brand-new avionics package. The glass cockpit with four large display units (DUs) was revolutionary and has gone on to be the cornerstone of some very good cockpits in the Gulfstream stable. The airplane got its type certificate on Aug. 14, 2003.

The next year, a line of computer code caused all four DUs to go blank on at least one crew while in flight. Before the code could be rewritten, Gulfstream issued Maintenance and Operations Letter G550-MOL-2004-0020 recommending the following procedure if the DUs failed to recover within 90 sec.:

If DUs DO NOT recover, continue checklist with Step 7:

(7) Advise passengers that normal power will be off.

(8) Left and right generators (and APU generator, if in use) . . . OFF.

(9) Wait 30 seconds.

Gulfstream issued a software update (Aircraft Service Change 902) that fixed the broken code in December 2004, but the FAA followed up the next year with an Airworthiness Directive that said noise interference in the avionics standard communications bus would interfere with the display recovery.

Technophobe Technique. Can you imagine flying across the North Atlantic at night with nothing more than a standby attitude indicator? For around $600 you can buy a portable WAAS GPS equipped with ADS-B In and an integral backup attitude system that will link with an iPad. This setup could be a lifesaver the next time ATC shuts down, or you discover a broken line of software code. That is cheap insurance for a multimillion-dollar aircraft.

The avionics suite in the G550 is a work of art and I can imagine there must be millions of lines of code behind it. Is it surprising that a line of code made the wrong decision reacting to noise interference? I do not know, but I can certainly sympathize with the software engineers. What can we, as pilots, do about this? Let’s look at one more example.

Example of a Nuisance Line of Code Error

We took delivery of our Gulfstream GVII-G500 within a year of the airplane’s certification and we had on board a Gulfstream test pilot who was more than just a run-of-the-mill Entry Into Service (EIS) demo or delivery pilot; he really knew his stuff. The first thing we did was do three takeoffs and landings at Savannah/Hilton Head International Airport, Georgia (KSAV), each with an ILS approach and a quick reloading of the flight plan in the FMS, all handled by our EIS pilot.

We then loaded a flight plan to Laurence G. Hanscom Field Airport, Bedford, Massachusetts (KBED). The FMS initialized the route with a speed of 160 kt. and cruise altitude of 180 ft. Try as we might, we could not change that. Our EIS pilot called all the company experts and they all said, “We’ve never heard that one before.” Finally, someone suggested pulling and resetting the Modular Avionics Units circuit breakers. That worked, but it made the cockpit go nuts. I told the EIS pilot, “Let’s never do that again.”

The pilots at Gulfstream were stumped. But how often did they fly a local pattern and then set up for a Point A to Point B trip? Perhaps never. I reached out to a GVII users group and discovered that a few operators already found a workaround: Hit the Take Off/Go Around button on the thrust levers to fix things. That worked. After some experimentation, we discovered the problem only seems to happen after flying an ILS, shutting the engines down but leaving the avionics powered, and then entering or downloading another flight plan. We made several videos of the problem and now the avionics manufacturer is hunting for a line of code to fix for a problem never anticipated.

Technophobe Technique. Manufacturers and training vendors tend to live in sterile bubbles where conditions are largely predictable. There is no way they can anticipate and simulate every possible condition “out there” in the real world. It is in everyone’s best interest if those flying a particular aircraft type connect with the rest of the community and share experiences. In the few months I have been flying our new airplane I’ve already discovered a few problems that stumped Gulfstream and our training vendor but found answers in a user’s group. “They” build the airplane or train us to fly it. But “we” have more relevant, real-world experience. We should share that knowledge.

Technophobia as a Survival Mechanism

Science fiction writer Arthur C. Clarke formulated a series of adages that became known as “Clarke’s Three Laws” and of those, the third, applies: “Any sufficiently advanced technology is indistinguishable from magic.”

It is tempting to think of those millions of lines of code that go inside our computers as magic. As such, only someone who thinks in ones and zeroes can hope to understand them and the rest of us are at the mercy of the magician. As modern-day aviators we are immersed in technology and the stakes are too high to leave our fates to sorcery. But we can anticipate the unpredictable by playing the “what if?” game and developing techniques to survive.

Technophobia, it would seem, is a valuable tool if used wisely.