Acceleration

These last few days I've been indulging my nerdy streak and experimenting with Accelerate-Stop distance calculations. A while back I wrote a blog (found here) regarding Accelerate-Stop distances and the balanced field length of the Twin Comanche. That exercise came about as a result of a lack of Accelerate-Stop distance charts in my Twin Comanche flight manual, so I made my own. An Accelerate-Stop distance chart simply a chart that the pilot can use to determine the total distance required to accelerate to Vr (rotation speed), and then retard the throttles and stop using maximum braking. This distance changes depending on the field elevation, temperature, weight of the aircraft, and winds. These charts give a good indicator of the length of runway one would need to safely stop if they experienced an engine failure during the take-off roll.

I have recently been tinkering with an application that allows me to develop Apps for my Android Phone, called App Inventor. Its really quite fun, and while it does have some limitations on designing the user interface, it is really quite powerful on the functionality side. So I set out to design an Accelerate-Stop distance calculator for the Navajo. The Navajo does have proper Accelerate-Stop charts, but the challenge was in the ability to create a formula based on the variables present in paper chart in the flight manual. It ended up not being that hard, and after a day I managed to find a formula that produced results within +/- 50 ft of what the flight manual charts spit out. It took another hour to design and code a really simple app on my phone that makes use of the formula, allowing the user to input density altitude, loaded aircraft weight, and headwind component, and it makes the calculation. So now I have an app on my phone that can calculate Accelerate-Stop distances for a Piper Navajo.

I can't leave it at that however. That's way too easy. So here is the problem to solve: Accelerate-stop charts give a good reference, but they don't really have the flexibility of real-world operations. At least no more than just giving you a good idea. It still leaves room for ambiguity. In real life usually we're operating out of runways much longer than what is needed according to the Accel-Stop charts. For example here in France the runway is 5000 ft. So lets say for example that for the given day I check the accel-stop distance, and the chart (or my phone app) tells me the Accel-stop distance for that particular day is 3100 ft. So that means we can have an engine failure at Vr, and still stop with 1900 ft to spare. So if an engine quits on takeoff, up until Vr our go/no-go decision is a no brainer - we cut the power and stop. BUT, what if the engine fails AFTER Vr?

In theory we would clean the airplane up, continue climbing and return for a landing. But isn't that a waste of some really good extra runway? What if we still had the space to land and stop? Wouldn't that be a safer option than trying to climb out and fly an entire circuit on a single engine? Remember this is a light twin - climb performance will be extremely crippled on one engine. So how do we know if we have the space? An Accel-stop chart can't give you that answer, and that's a pretty tough decision to make in the chaos and confusion of a failed engine on takeoff.

This tough decision at a critical time is EXACTLY what every aircraft manufacturer and operator is trying to eliminate. In fact this is why manufacturers of large transport category aircraft do things a little differently than an Accel-Stop distance chart. Rather than using a chart that is only good up until one specific airspeed, they use charts/computers that do things the other way around. In addition to the normal variables like winds, temperature, and weight, the pilot will also input the length of runway he has to work with, and the computer program (or chart) will output an airspeed specific to those conditions (V1 - or takeoff decision speed). Below that airspeed, the pilot will have enough space to reject the takeoff and stop, above, he can be confident he has the space to fly away. There is no ambiguity with this method as its not based on one specific airspeed. If the runway is longer, takeoff decision speed (V1) increases to account for that extra length.

So that is the challenge for me. Create a computer program that rather than OUTPUTTING a distance like the Accel-Stop chart, it allows me INPUT the length we have to work with, and OUTPUT the takeoff decision speed that corresponds to that runway length (and the other variables). Easier said that done. I'm still working on it, but it has been a fascinating exercise so far. This is where math comes in, so I may lose the interest of a lot of my readers here, but if you're the kind of person who finds joy in applying math to real life, you'll LOVE this. The key to this whole solution is the kinematics formula of:

V = √2DA where

V = velocity (or our magic decision speed - V1)

D = distance

A = rate of acceleration

I get so excited when physics can be applied to real world scenarios!!

D is of course user-inputted, but A is going to be the magic value I need to figure out. This formula is for constant acceleration, so it doesn't COMPLETELY work out in the real world. In the real world as our velocity increases, so does air resistance to the square of velocity. This means that as we go charging down the runway, our rate of acceleration is actually diminishing as our speed increases - so how do we fit a changing rate of acceleration into the equation? The answer is to find our AVERAGE acceleration (from the point of stationary to our decision speed V1), and plug that into the equation - but how do we find that?

Well this is the fascinating challenge. I started by going to the Accel-Stop chart provided in the flight manual. This chart gives us two variables that we can use to find our average rate of acceleration - it gives us the distance of course (depending on the conditions), and it also defines the speed at which we accelerate to - which is 89 mph. The distance however is distance it takes to accelerate to 89 mph, and then decelerate back to 0, so we have to separate those two distances. There's an easy way to do this - the flight manual also provides a takeoff performance chart which gives the ground roll distance to accelerate to Vr. This is perfect, it gives us our acceleration distance right there, and we can get our deceleration portion by subtracting that from our Accel-Stop distance. Now we can calculate our average rate of acceleration for the acceleration portion, and the same for our stopping portion. We do this using this formula:

A = V^2/2D

Its the same formula as above, just solving for A instead of V. Simple. Now we have our value for rate of acceleration - so we've made some progress! Except we're not quite there because this acceleration value is only valid for one speed - the speed defined in the Accel-Stop chart. Because as you remember our rate of acceleration is going to change depending on our speed and the corresponding wind resistance. If we make our V1 speed higher than 89 mph, our average acceleration value will be less, if we make our V1 speed lower, our average acceleration will be higher. This is where it gets REALLY interesting, because some experimentation is in order, and this is where I haven't figured everything out yet, so I'm really enjoying it as a good brain challenge.

I know that I can calculate acceleration by using:

A=V/t

where t is time. So when we take-off I can time how long it takes to accelerate to a number of different speeds to get a good range of data (for example take the time as we pass through 60 mph, 70, 80, 90, and 100) and then we can plot that as a curve and extrapolate/interpolate as needed and calculate our average acceleration based off of that. OR......

I can download an app on my Android phone that records measurements using the phone's accelerometers! I found a neat app that does just that, and charts the measurements as G's on all 3 axis. 1 G equals 9.81 m/s^2, so that's easy enough to convert the G measurements into acceleration. I've been playing with this feature for the last couple flights, and I must say, it works amazingly!! The app allows me to export the data into a spreadsheet. I can then calculate velocity from the raw G readings and graph it in excel.

Check THIS out:

This is a graph of today's takeoff taken from the data collected by my phone's accelerometers, and charted as speed (mph) over time (seconds) in excel. Isn't that a beautiful curve!?! Who would have thought I'd be able to produce such a beautiful curve from real world data collected by a smartphone!! Amazing. I haven't doctored the data at all except to delete everything after the point where we were airborne. Note the takeoff roll doesn't start until 6 seconds in, because that's the time between when I started recording data and when the Captain started the takeoff roll. So our takeoff roll took roughly 27 seconds, and we were airborne at a speed of around 110 mph.

Also note the sharp increase in acceleration at very beginning (probably due to the throttles being advanced and more power being added), and then the gradual decrease in acceleration (shown as the slope of the curve) as we picked up speed and air resistance became a bigger factor. I know the phone's sensors are kicking out accurate readings because the results I achieved were bang on the money with our airspeed readings (it was a calm day). I never imagined in a million years the data would come out this clean.

Using this data I can calculate our average acceleration at ANY airspeed, which I can then use to find our distance traveled (with I think a fairly high degree of real world accuracy). Voila! We have the brain behind our computer program.

The only problem is that these acceleration values are only good until we become airborne. After which there's a whole new set of kinematics in play that I still have to figure out, but I'm fairly confident with a few more data-recording sessions in the airplane and some math I'll be able to nail it down. Once I do, its a matter of writing the computer program to process the math and solve for velocity, and bingo, we can figure out exactly what decision speed corresponds to our given runway length.

I know, I'm a nerd, but seriously, isn't it amazing when you can use math, an android smartphone, and computer programming to make something useful?

Procedures Pay Off

I am happy to report that I totally greased my two subsequent landings after my last post. One of which was in a light crosswind. I think I've finally got the feel for this airplane now. Now we'll start working on nailing the touchdown point.

Our last flight lasted 8 minutes, and now we're grounded waiting for parts. An engine driven fuel pump that is. I was PNF (Pilot Not Flying) for that flight, so my duties involved monitoring engine instruments on take-off and making the required cockpit calls (Full Power Confirmed, Gauges Green, Airspeed Alive, 95 mph, Rotate, etc) and completing the after-takeoff checklist.

We took off, everything normal, and I started to complete the after-takeoff checklist on our climb through 500 ft. As I turned off the left Emergency fuel pump I watched the fuel pressure gauge to make sure the pressure didn't drop out (which would indicate an engine-driven fuel pump failure, and an immanent engine failure). Except this time as I flicked off the overhead switch the pressure DID drop out. Huh, didn't expect that.

At about the same time I watched the drop in fuel pressure, the Captain saw the Low Fuel Pressure light illuminate on the enunciator panel. I quickly flicked the switch back on just as the left engine started to cough. We turned around and landed without incident.

This is a very good example of why emergency fuel pumps exist, and why we employ the good practice of turning them on for take-off, and then then turning them off one at a time after takeoff. And also in a broader sense of how airplanes are designed so that stuff can break, but the airplane can still fly just fine.

Just like a Twin Comanche, the Navajo is equipped with an engine driven fuel pump, which does just what its name says. Normally the engine driven fuel pump is what provides fuel to the engine in normal flight, but if it were to fail, the engine would stop producing power. So we have a set of emergency fuel pumps, which do the same thing, except they are powered electrically as a back-up system. Without the emergency pumps turned on it would be a real bummer if the engine driven pump failed during takeoff, because that would mean the engine would quit, and we'd be stuck troubleshooting a failing engine during the most critical and time-sensitive phase of the flight. So its good practice to turn the emergency pumps on for every take-off we perform. That way if the engine driven pump fails, it will only affect the performance of the engine when we go to switch the emergency pump OFF.

So that's what we do. We only switch OFF the emergency pumps after we're a certain height above the ground such that we have time to troubleshoot potential problems without immediate action being required. Furthermore its good practice, for obvious reasons in light of our last flight, to turn off each fuel pump one at a time, and watch for any changes in fuel pressure. If we were to flick off both pumps at the same time, it would be far less intuitive to correctly identify which engine was in the process of failing.

On Tuesday all the cautious procedures paid off, and our fuel pump failure was a non-incident. Had we not been exercising good practice it is very possible we would have had an engine failure during takeoff.

The system works.

Landin... wait... ok Landings

*CHIRP*...................*Chirp* Dang it. I bounced it again. But I know exactly what I did wrong. I'm having trouble nailing down a good landing in the Navajo. I haven't really gotten that much practice lately. The Captain and I usually alternate Pilot Flying duties every flight, but the last two flights that were supposed to be mine the Captain ended up doing the landings because it was fairly gusty with a bit of a crosswind. I'm not complaining, I still don't feel perfectly at home yet in the airplane, and would rather get my practice in on calmer days. Part of it has to do with the fact that I've never flown an airplane from the right seat before, so I have to develop some new muscle memory skill sets. What used to be my throttle hand is now my flying hand, and my flying hand is now my throttle hand. Its also quite a bit bigger airplane than I have experience in.

This time the the reason I bounced all tied back to not having a stable approach. Normal approaches in the Navajo are done at 120 mph, and as we cross the airport fence we pull off the power slowly and let the airspeed bleed off so we're around 110 mph crossing the runway threshold. I'm finding that the Navajo is fairly sensitive to power changes, and it builds speed fairly quickly and doesn't lose it easily. Initially as I turned base I had the airspeed pegged at 120, but I found myself a little high, so I pushed the nose down and pulled off a touch of power, but apparently not enough, and soon enough I found the airspeed way up past 130 - way too fast. I spent the rest of the approach trying to work it back down, and ended up crossing the threshold carrying way too much speed. We floated for a long while in ground effect waiting for it to slow down, until the Captain eventually called me to chop the power cause we would be running out of runway soon. I pulled the power back to idle, and then that resulted in a bit of a firm landing with a small bounce.

That was a couple days ago, and today it was my turn again. This time I made sure I had the airplane properly slowed down and the approach speed and glideslope pegged with lots of time to spare. I made sure I stayed much more aware of my airspeed during power adjustments, and made a decent landing this time with no bounces. Still room for improvement, but we'll get there.

On a separate subject I saw a Twin Comanche doing touch and goes at our airport a few days ago. I couldn't help but stand and watch for a bit. It brought back memories, and made me wish for a few moments that I still had mine. It was just so much FUN.

Flight Planning

Part of the requirements of our permits that allow us to overfly small communities at low altitude is that we have to notify each town when we'll be overflying them. Part of that involves faxing a map of our flight path off to each town hall as well. So far I've compiled a database of over 100 small communities in our survey block that we've been notifying when our flight for the day takes us over them. Its tedious work to determine when exactly we'll be overflying each town, and which ones. So why put up with tedious monotony when you can write a computer program to do it for you?

I've gone over almost the entire map now, and recorded in a spreadsheet the names of the towns and the line # that runs over top of them. Every flight line in our grid is numbered, and the company geophysicist, who processes our data keeps a spreadsheet list of each numbered line, and how long it is. So after obtaining that, I've written a VBA (Visual Basic for Applications) excel program, and now I can specify the line # we're going to start our flight on, and the time we're going to begin surveying, and my VBA program will chew through my database of communities and the geophysicist's spreadsheet of survey lines, and spit out a list of each town we'll be overflying for that particular flight, and the start and end time of each line we fly. I send that list over to the Captain, and he sends out faxes to each community with the calculated time we'll be flying overhead. Done and done.

Now I don't have to spend hours pouring over the map calculating what towns and when we'll be flying over them. It just takes 10 seconds to get the program to spit me out a list, and if we change our flight plan I've only wasted 10 seconds and not an hour. Its also useful to find out how many lines and line kms we can expect to fly for the day. Its always fun when a hobby like computer programming becomes useful.