I’m trying to input some performance data into some flight planning software. Unfortunately the data I have available is in a different format to the format required for the software.
The data is split into climb, cruise, and descent. The cruise data is straight forward but the climb data that I have is in the form of time and fuel burn required for a complete climb to the selected altitude. For example to get to 27000 feet takes 24 minutes and uses 1300kg of fuel. The software requires that data as instantaneous climb rate, fuel consumption, and speed in feet per minute and knots. The speed is easy but I’m having trouble with the climb rate and fuel consumption.
The question is, given a table consisting of total time and total fuel for climb to altitudes from 0 to 31000’ in 1000’ increments, how can I derive the instantaneous rate of climb and fuel consumption rate for each altitude? The flight planning software will use the instantaneous figures to arrive at its own time and fuel required for the climb, these results should match those in my raw tables.
The tools I have available are a calculator, Microsoft Excel, and Apple Numbers.
I can provide the table data if you need it. I also have the same data in graph form, this more accurate as the tabulated data has times rounded to the nearest minute which means that some adjacent altitudes have the same time.
I’m confused here.
Is your flight manual information in graph format?
Are you looking for the “time and burn” between each altitude? (IE, fuel burn FL 210 to 220)
Aren’t there other factors, air temp, density alt, aircraft weight, etc. that would change this?
ETA
(wow, plight planning has come a long way in such a relatively short time. I bet Lindberg would have loved this tool when flying the mail, at night, across this country)
If you subtract the total time & total burn for one altitude from that of the next higher altitude, you’ll get time and burn for that 1000’ increment. This gives minutes per 1000 feet and burn per 1000 feet. Call those *m & b. Then climb rate in fpm C = 1000/m, and instantaneous FF in weight per hour is F = 60**b/m. If the burn is in kg/hour then the FF will also be kg/hour. Likewise if the burn is in pounds, the FF will be in pounds/hour. Those C & F numbers will be what your software wants as input. To be sure, each of those are averages over a 1000’ increment vice the instantaneous value at the start of each 1000’ increment. But compared to what I’m about to say, that source of error is way down in the noise.
Of course what you’ll find is these numbers are all over the map due to the rounding that went into creating the table. So you’ll have to manually smooth them out by adjusting each of them up & down a bit until the rate of climb declines more or less smoothly, as does the FF.
I suggest you graph the raw results and visualize the best fit curve that approximates the raw numbers. Then input those in a separate column and graph them on the same chart. When the smoothed numbers make a curve that looks like it nicely fits the “average” of the jumpy numbers, you’re done.
If you can start from performance graphs and pull your own raw total times to climb and total burn to climb, you’ll probably have more detailed numbers to start the smoothing process with.
In any case it won’t be an easy or highly accurate process.
When you’re done the output of the software ought to be fairly close to the original data. But it won’t be a precise fit.
The flight manual has the information as a graph and then it also has the same info in a table for ease of use. Temperature, weight, etc do make a difference, and there are numerous tables to cater for each variable, but by erring slightly on the conservative side the variations don’t matter much, also our operation has limited variables. The temperature is normally standard plus 10°C (ISA+10), our weight is typically close to the max landing weight plus the fuel burn for the leg and the legs are usually between one and two hours long, so useful numbers can be extracted by using those basic assumptions.
The flight planning is just an iPad app that I’m playing around with, our real flight planning is done by the company (and they make much the same assumptions).
LSLGuy, I should have said, I’ve pretty much tried your suggestion though I didn’t carry the idea through as thoroughly as you are suggesting. As you say, the resulting data is a bit all over the place, but I think I can improve it. The most accurate way will be to make my own tabulated data from the graphs without rounding the results as much. What I was hoping for is that someone who knows a lot more about graphing functions might know away that you can basically plug in the tabulated data and get instantaneous data I’m after, that it will be derived mathematically rather than using the old TLAR method. I suspect I will need to get into the graphs though.