# Using Level Accelerations to Determine Climb Performance

### Help Support Homebuilt Aircraft & Kit Plane Forum:

#### wsimpso1

##### Super Moderator
Staff member
The question how accurate does our altitude hold need to be is perhaps best turned around into how accurate do you want your Vy and ROC estimates to be? If we are estimating what the rate of climb is at any one speed by only using acceleration, and our altitude is oscillating, the oscillation in the accel data is spurious. If we want really smooth ROC estimates, we can not be shifting energy back and forth between potential and kinetic energy.

Let's say we want our instantaneous ROC to be good to within 10%, then w*dh/dt has to be no bigger than 10% of m*a(t)*v(t), where w is weight, dh(t)/dt is climb/descent rate in ft/s, m is airplane mass (weight divided by the acceleration due to gravity), a(t) is accel measured, and v(t) is airspeed measured in ft/s. The potential energy in any one time step needs to be smaller than 10% of the change in kinetic energy. If altitude is moving around too much, reformulate the excess thrust calculation for each time step to include the altitude term.

If the pilot is operating in air that is steadily rising or descending, this method can still work for selecting Vy and Vx. Determining exactly what the climb rates are will take still air.

Billski

#### BJC

##### Well-Known Member
Supporting Member
If done in an airplane with an EFIS, accelerating in level flight is easily accomplished by keeping the velocity vector on the horizon line.

Edit: I would trim for max speed before starting the acceleration test. I find it easier to fly precisely with lessening back pressure on the stick rather than increasing forward pressure.

BJC

Last edited:

#### FinnFlyer

##### Well-Known Member
Poor flying (me) does show up in the data. Thus multiple runs at each altitude and weight.
For example my first 4,000' data is significantly off compared to the other altitudes and needed to be redone.
My traditional "saw tooth" testing was even worse, even after weeks of testing. Very hard to find days with identical conditions. The acceleration method at least gives me a chance to get meaningful data, once I get good enough to keep altitude within 25' as noted in the article.
When looking at the acceleration segments in the EFIS datalog, I graph both the altitude as well as the airspeed, to see how well (or badly) I kept the altitude.

Whereas I could pick 6th order polynomials (displayed with 10 or more digits), I do try different orders. It's easy to copy the trendline equation, do a search/replace in Notepad of x with *A2^ , paste into cell B2 and drag it down all the rows and see the curve result. So I don't just blindly use the data from the EFIS datalog.

Anyway, in my case what needs to be improved is the data collection (precision flying), and I think I have a better chance learning to keep level altitude than keeping airspeed constant during climbs.

Finn

#### FinnFlyer

##### Well-Known Member
If the pilot is operating in air that is steadily rising or descending, this method can still work for selecting Vy and Vx.

I think this is key for me if I don't want to wake up neighbors before sunrise and don't want to wait till fall or winter.

BTW, no particular reason why column A in spreadsheet could not be in 0.5, 0.25 or 0.1 second intervals. But would that compensate for altitude excursions? How does the displayed R-squared relate to that? (I don't even know how that is calculated. Just know it's a measure of how well the trendline fits the data curve.) I suspect not, unless altitude (variation) is incorporated into the equation.

Finn

#### Toobuilder

##### Well-Known Member
Supporting Member
Altitude excursions pollute the data. How significant is the pollution? Up to you, the Test Conductor.

#### HoHun

##### Member
Hi,

How about augmenting the data collected by using a total energy vario?

That sounds like a great idea. Actually, it might not even be necessary to have an actual cockpit instrument for that ... if one can be certain that the logged altimeter data points are free from lag, it should be relatively simple to calculate the height-change corrected acceleration from the logged data points.

As presented in the article, the accuracy of the approach seems to be a bit limited. Looking at the "Rate of Climb Vy" diagram, the value of about 94 KIAS @ 14000 ft seems quite suspect, considering that the neighbouring data pairs are 86 kts IAS @ 10000 ft and 72 kts IAS @ 18000 ft. One would normally expect the 14000 ft value to fit in between these. The other altitudes line up better, but such an outlier is not really confidence-inspiring, in my opinion.

The author correctly points out:

One thing you will notice about the climb performance of RVs is the top of the curves are relatively flat. This means that over a wide speed range, there is only a small change in climb rate. This insensitivity is a good thing.

On the flip side, this also means that it's difficult to determine the exact speed at which the flat curve actually peaks.

Regards,

Henning (HoHun)

#### wsimpso1

##### Super Moderator
Staff member
I think this is key for me if I don't want to wake up neighbors before sunrise and don't want to wait till fall or winter.

BTW, no particular reason why column A in spreadsheet could not be in 0.5, 0.25 or 0.1 second intervals. But would that compensate for altitude excursions? How does the displayed R-squared relate to that? (I don't even know how that is calculated. Just know it's a measure of how well the trendline fits the data curve.) I suspect not, unless altitude (variation) is incorporated into the equation.

Finn
R^2 is the correlation coefficent. R^2 =1 is a perfect fit between your data and equation at the points where your data was used. R^2 less than 0.95 in the hard sciences (airplane performance is) maybe acceptable. In the social sciences, 0.50 is frequently acceptable. Look here:

For an equation to have meaning you must have enough points for the function you are picking and the shape of the data. Enough is kind of subjective. I can think of a bunch of ways this can be messed up.

Classic is two points, and an equation of this form y = c1 + c2*x fits it perfectly. This is OK if the function is a straight line - an example is distance at a constant speed. If instead the data is travel with constant acceleration, y = c1 + c2*x +c3*x^2 is known to describe it perfectly.

Another classic is N number of data points and an N (or greater) order polynomial. It will fit the points perfectly, but between points it can be all over the place and thus does not describe what is going on very well either. Imagine 4 data points with a 4th order equation - perfect fit that does not reflect reality. So pick a function that has a shape that fits with the data.

The topic of multiple runs at one starting point has the advantage of averaging. Best way to do this is to combine data. If the time bases do match (t=0 is not the same starting speed for each run), they can be corrected by adding an offset to each time column to make the starting speeds line up, then proceed with curve fit for entire set. Use enough runs and this technique tends to average out the oscillations and other noises in the data. R^2 may not be better, but the equation will usually fit the real world better, which is the goal.

All the comments on how many decimal points to show is sort of missing the point. In my world, I need something like 3 or more significant digits for me to trust the outcome. For number less than unity, the zeros between the decimal point and the first non-zero digit are meaningless. If you are running fourth or higher order polynomials, the coefficient for the fourth order term can be pretty darned small and still have meaning. If you get less than three significant digits, please expand the equation display or change it to scientific notation with enough digits.

Billski

Last edited: