Isa Speed Testing (Yak And 190 So Far)

March 7, 2015

I agree but I assume most people who attempt to do climb tests know the rules to stick by i.e. not starting your test at 400 Kph. By starting and ending at the optimum climb speed and doing your best to keep the speed constant should reduce the errors and at that speed there is little zoom climb available unless you try to cheat and pull the stick back at 6900m. Having done this test several times I think an autopilot program would get a fairly similar result maybe a little better.

You can fly it by hand and get a very good approximation. Fly the profile several times to ensure your results are repeatable.

I would recommend using a saw-tooth climb schedule over a variety of speeds as that will give you a good baseline for calculating the aerodynamic data. That will tell you if the Power/Thrust available to Power/Thrust available curves are correct for the design.

Here is a good primer for data selection, reduction, and schedules for saw-tooth climb testing. It is not hard to do. It just takes a little time but will tell you exactly what your game aircraft are doing. Of course, do it in ISA conditions to establish a baseline and then that data can be converted to any atmospheric condition.

http://www.aero.polimi.it/~chimetto/bacheca/downloads/docs/NASA03SawtoothClimb.pdf

March 7, 2015

I love it when NASA agrees with me!

March 7, 2015

Here is another sawtooth climb schedule:

Notice the speeds in the profile start out at 100 Knots, 110 Knots, and 120 Knots.

The climb speed can be set by the tester. I would recommend looking in the POH for the aircraft being tested and start out ~20-30 Knots slower and increase speed until you no longer get a reasonable climb rate.

This information can then be used to find the actual best angle of climb and best rate of climb speeds for the aircraft in the game.

I love it when NASA agrees with me!

[Edited]

Edited March 7, 2015 by Bearcat

March 7, 2015

Yeah, because I gave you this stuff years ago when you were screaming about the Bf-109K in IL2 using non-standard conditions to compare to standard data.

Crump,

Please stay on topic.. Don't get this thread locked like you have so many others by trying to make it personal! If you feel the need to tell me all the things you 'think' you have taught me, than please make use of the PM system here and spare the members of this forum and thread.

Thanks in advance!

March 7, 2015

Guys, guys...

You all seem to make proper climb testing seem so hard, when in reality, you are all doing it wrong. As a former FM dev, I know how frustrating this can be for both players and devs alike.

Here is one of the last posts I wrote about the topic on a similar internet virtual pilot/forum warrior coliseum. Take from it what you want:

""""

FACT:

99.99% of virtual pilots do climb tests wrong, as compared to the methods used by USAF, RAE, and US Navy Test Pilot School. (I realize neither the Fw-190 nor the Yak are from these countries, but this semi-standardized method is still the same.)

If you are flying with a stopwatch, timing your climb, then comparing the results to historical documentation, you are doing it completely wrong. Not only is it impossible to replicate a time to height curve (explain how you can have 5000 ft/min climb rate as you pass out of the ground...), it's impractical and is beyond the original intent of what a time to height curve represents.

Time to height in historical documentation, unless otherwise stated, is "integrated" (a calculus term) from instantaneous rates of climb at specific speeds measured at specific altitudes. This gives a standardized method of presenting the performance of an aircraft in climb on paper in such a manner as to separate pilot error from the performance of the airframe. In testing with a stopwatch, errors are cumulative and any changes in your normal acceleration (load factor, or g) have an impact on the rate of climb.

Is it possible to fly a perfect 1g climb? Absolutely not. Not even for the best test pilots in the world.

However, the downside to measuring climb correctly is that it can be somewhat time consuming if you seek unrealistic "degrees of accuracy" in terms of the number of altitude bands you are wanting information for. While I will not go into excruciating detail here about correcting results to standard day values (use Test Flight and it's already done for you), I will give you a general idea of the procedure and will use a table from "Historical Data" to illustrate the proper method:

Choose a range of altitudes that you are wanting information for. In practice, I've found 2000-3000 ft bands of altitude gives the best compromise between time invested and error incurred. It's important that you measure rate of climb on or near the critical altitude of the supercharger stages.
Log the altitude, instantaneous rate of climb, and your target CAS airspeed as you cross each band. Be extremely careful that your aircraft is trimmed to fly hands off at your target CAS as you pass through the band.

If you mess up, just throttle down, dive below that altitude, and try again until you get it right. This alone is a tremendous time saver versus recording with a stopwatch.

In order to find the maximum performance time to height, you will need to try different values of CAS at each altitude band. The general trend you will find is to hold some optimal CAS until you are at or near the critical altitude for the last gear of the supercharger. If you goal is to compare your measured TTH with historical information, you must use the CAS listed in the climb table. Here IAS is given without PEC, however it's safe to assume for most planes that the PEC at or near climb speeds is minimal.
Take this table of information a load it in a spreadsheet like this:
Estimate the rate of climb at SL based on the next value(s). Here I conservatively set it below the climb at 1700 ft due to the critical altitude in this stage being at 1700ft. Generally, the RoC at SL can be linearly extrapolated from the following two bands, provided they are both below the critical altitude of the first supercharger stage. After the complete TTH is calculated, you can experiment with ths precise value and you will see that it does not have as much of an impact on total TTH as you would think provided the next available altitude is within 3000-5000ft above SL.
Find the change in altitude between consecutive bands, and apply to all bands:
Calculate the average rate of climb between consecutive altitude bands, and apply to all bands:
Find the time to height by dividing the change in altitude (dHeight) by the average rate of climb, and adding it to the previously calculated value. Set the time at SL to zero, and begin at the second altitude band.

Here you can see the values between calculated and historically listed are almost exactly the same. The error in the results comes from the specific simplified method of integration I've chosen (Trapezoid method) but in practice more involved methods of integration do not result in lower error. You can see however that the resulting error is insignificant for most of the altitude bands, thus leading me to believe the TTH in the table is rounded, but rate of climb is nearly exact. This is a fine example of why unquestioning acceptance of historical data is extremely dangerous.

Even with my conservative estimation of 5000 ft/min at Sea Level the results come in faster in time to height of the first band despite the original plotted chart showing the same ROC as at 1700 ft.

http://www.spitfireperformance.com/JF319-climb.jpg

And here is the resulting "Time to Height" chart:

Reference Data: http://www.spitfireperformance.com/jf319.html

For all intents and practical purposes, measuring with a stopwatch will give you a rough idea of the performance and is fine for informal measurement. But if you must compare an FM to historical data, at least be fair and measure it with the same method used to generate that historical data. Only then will the results be taken seriously.

"""

Hope you find it useful.

Respectfully,

Ik

March 7, 2015

Awesome info, thanks!

March 7, 2015

For all intents and purposes, everything you said agree with what I have been saying.. Except for a few points..

""""
FACT:
99.99% of virtual pilots do climb tests wrong, as compared to the methods used by USAF, RAE, and US Navy Test Pilot School.

That is what I determined over the past 10+ years of reviewing virtual pilots ROC tests..

If you are flying with a stopwatch, timing your climb, then comparing the results to historical documentation, you are doing it completely wrong.

Some what agree here..

As I have been saying, don't even try worry about making note of the time or instantaneous ROC while preforming the ROC test.. Put all your focus on pitching the plane to maintain the desired climb speed..

Than post test refer to the time and instantaneous ROC values.. But, to do that, you have to record the track file and than review it post test.. Which is basically what they did/do now, where the track file takes the place of instrumenting the aircraft to log data..

Time to height in historical documentation, unless otherwise stated, is "integrated" (a calculus term) from instantaneous rates of climb at specific speeds measured at specific altitudes.

AFAIK most of the tests done in WWII were actual timed tests and not integrated vs how they did/do it post WWII.. In WWII the US ROC testing was done from a dead stop on the runway.. The 'time-to-climb' started once the plane started rolling.. The understand their reasoning you have to put yourself in their shoes.. Just prior to WWII, radar was a new thing.. And air forces were very concerned with intercepting enemy bombers.. Therefore when they tested, they were very interested in how long it takes a plane to get to a certain altitude starting from a stop on the runway.. Not all countries did it like the US, some started with the plane in flight at an altitude of a few hundred feet, flying at the intended climb speed, the time-to-climb started once the pilot pulled into the climb.. But, all the air forces were very, how you say, didn't trust 'calculations' and had the 'show me' approach to testing..

Note, this is not to imply that you can not obtain the time by integrating the ROC, I am sure they did that as a sanity check.. All I am saying is that is a more modern method, post WWII, that is to say, up until the 1950s, climb performance and level top speed and acceleration were treated as separate and distinct performance parameters, each with their own unique flight test requirements, data reduction, and analysis.

In the 1950's Edward S. Rutowski (Engineer working for Douglas Aircraft) realized climb performance and level acceleration were really different aspects of the same characteristic, and stated that aircraft performance is based on..

“The balance that must exist between the kinetic and potential energy exchange of the aircraft, the energy dissipated against the drag, and the energy derived from the fuel”.

This gives a standardized method of presenting the performance of an aircraft in climb on paper in such a manner as to separate pilot error from the performance of the airframe. In testing with a stopwatch, errors are cumulative

True, but if all the required data is being logged, the accumulated errors can be accounted for.

and any changes in your normal acceleration (load factor, or g) have an impact on the rate of climb.

Agreed 100%

As I have been saying, holding a constant climb speed is allot harder than some think it is.. And what makes it hard is that they don't even realize how much their climb speed is varying.. The resolution of the IAS gauge is not that great, you have can very large variations in speed and not even realize it..

NASA testing state as a measure of a successful test is 'IF' the climb speed did NOT change by more than ~3.5mph during the test..

And based off the original IL2 ROC tests I reviewed, it was typically never that good and typically well above 10mph worth of variation.

Which as you noted, results in accelerations, which in turn causes spikes in the instantaneous ROC values.. So, depending on when the pilot looks at the instantaneous ROC value (assuming they have a gauge for it) it can affect the virtual pilots results, if he looks during a positive acceleration, he may be fooled into think the plane is climbing better than it should, if he looks during a negative acceleration, he may be fooled into thinking the plane is climbing worse than it should.

In light of this, and the fact that we can not log data in this game, I think the instantaneous values of ROC are going to be hard to use.. Which is why I recommended calculating the averge ROC between to altitudes, the assumption being (and it is a big one, but not unlikely) that the virtual pilot will be 'oscillating' around the constant climb speed, as in sometimes a little above it and sometimes a little below it, therefore the average of it should be a decent value. The trick is to pick a time interval that is big enough to allow this 'cancelling' effect to happen, but not so big that your ROC is changing due to the fact that it will change as you climb.

Is it possible to fly a perfect 1g climb? Absolutely not. Not even for the best test pilots in the world.

Agreed 100%

However, the downside to measuring climb correctly is that it can be somewhat time consuming if you seek unrealistic "degrees of accuracy" in terms of the number of altitude bands you are wanting information for.

Very much so!

As I pointed out to find the best ROC, you have to try several different climb speeds.

As for the rest, I think we agree, only thing I would suggest, is no mater which way you do it, you should use the other method as a sanity check of the other.

March 7, 2015

In light of this, and the fact that we can not log data in this game, I think the instantaneous values of ROC are going to be hard to use.. Which is why I recommended calculating the averge ROC between to altitudes, the assumption being (and it is a big one, but not unlikely) that the virtual pilot will be 'oscillating' around the constant climb speed, as in sometimes a little above it and sometimes a little below it, therefore the average of it should be a decent value. The trick is to pick a time interval that is big enough to allow this 'cancelling' effect to happen, but not so big that your ROC is changing due to the fact that it will change as you climb.

i.e. Steps 1-7

March 7, 2015

It's a great discussion but it would be awesome if someone would prove me wrong by their own tests. At the moment I maintain that the Yak-1 is climbing much too fast compared to historical data (if that chart is correct).

March 7, 2015

i.e. Steps 1-7

No, I got it!

I see that your doing a sanity check of the instantaneous ROC values by calculating the average ROC value..

My point is

You are saying to use instantaneous ROC value as the baseline and using the average ROC value as a sanity check..

I am saying to use the average ROC value as the baseline and using the instantaneous ROC value as the sanity check..

In that as you and I both noted, the instantaneous values can be very 'noisy' due to all the virtual pilot errors you and I both noted.

In English, I trust the average values more than the instantaneous ones

In summary

Your approach to validating the ROC is to compare the real world time-to-climb to the in-game time-to-climb..

The idea being if the difference in the two is small, than the ROC is valid at that interval..

Where as up to now..

The topic approach to validating the ROC is to compare the real world ROC to the in-game ROC..

The idea being if the difference in the two is small, than the ROC is valid at that interval..

The later being more straight forward, and does not require any aditional math..

Which is not to say the time-to-climb comparison is better or worse..

All I would point out is to do it..

You not only have to have the real world ROC data, but you have to have the real world time-to-climb data and associated real world climb speed..

Which is two things alot of real world test data does not include (time-to-climb and climb speed)

Therefore, why not just get good at comparing the real world ROC to the in-game ROC?

In that if you don't have the real world ROC, your kind of dead in the water anyway.

March 7, 2015

Ikarus' timestamp='1425751338' post='241319'] In order to find the maximum performance time to height, you will need to try different values of CAS at each altitude band.

You just explained saw tooth climbs.

March 7, 2015

You just explained saw tooth climbs.

Not really. There is a difference between explaining how to perform a sawtooth climb, and explaining how to reduce the data to a proper climb test chart. The sawtooth climb is just a means to finding the optimal, not the end.

For instance, one would not use a sawtooth climb to match historical documentation.

The point of my posting is to explain how to use data, collected by whatever means necessary, to create a chart that is representative of what a time to climb chart is supposed to show, i.e. NOT a time history of a specific flight, but a representative characteristic of an aircraft's performance under certain conditions.

Edited March 7, 2015 by [JG2]Ikarus

March 7, 2015

Which is two things alot of real world test data does not include (time-to-climb and climb speed)

Therefore, why not just get good at comparing the real world ROC to the in-game ROC?

In that if you don't have the real world ROC, your kind of dead in the water anyway.

Time to climb can be integrated from a digitized RoC vs altitude graph (i.e. here Steps 1-7 again ), climb speed will generally be given in manuals.

In the case of NO data available, one must use dedicated saw-tooth climbs to find the optimal, but here there is no point in saying an FM is over or underperforming as you have NO measure of a baseline for an over/under comparison.

It's all pretty simple really

Edited March 7, 2015 by [JG2]Ikarus

March 7, 2015

Time to climb can be integrated from a digitized RoC vs altitude graph (i.e. here Steps 1-7 again ), climb speed will generally be given in manuals.

Any chance you could give us an example track/video using the Yak-1 in BOS?

March 7, 2015

Any chance you could give us an example track/video using the Yak-1 in BOS?

Sadly no. I cannot run the game good enough to even play it enjoyably, much less have the ability to record anything. This thread was brought to my attention by a friend pointing out that these discussions seem to be very common and similar, but troubling nonetheless. Having dealt similar discussions for the better part of the last year and a half, I figured I would try and help somewhat with the details of getting it right and being objective.

Proper climb charts and tests are not as obvious as they seem. It wasn't pilots that used these. It was engineers and decision makers, so all can be forgiven for misinterpretation and distortion of their original purpose.

Edited March 7, 2015 by [JG2]Ikarus

March 7, 2015

Time to climb can be integrated from a digitized RoC vs altitude graph (i.e. here Steps 1-7 again ), climb speed will generally be given in manuals.

Generally?

Most of the real world WWII data I have seen does NOT include the climb speeds..

Especially the early war stuff, some of the later RAF and US stuff does..

In the case of NO data available, one must use dedicated saw-tooth climbs to find the optimal, but here there is no point in saying an FM is over or underperforming as you have NO measure of a baseline for an over/under comparison.

Ah, good so you agree with me..

When I said your dead in the water if you don't have the real world ROC data

It's all pretty simple really

The concept is easy, but it is easier said than done! Edited March 7, 2015 by ACEOFACES

March 7, 2015

Generally?

Most of the real world WWII data I have seen does NOT include the climb speeds.. Especially the early war stuff, some of the later RAF and US stuff does.

Perhaps you are right, but every plane that has a Pilot's Notes or manual, has a suggested speed for climbing. This is what Pilot's notes are for.

Ah, good so you agree with me when I said your dead in the water if you have not ROC data

Yep, but all hope is not lost. It's actually possible to get fairly accurate(read plausible) RoC information from having good engine information and using aircraft performance computations based on dimensions and geometry. But sadly, if a plane lacks RoC data, it will typically lack good installed engine power data as well. Only then are you 100% screwed. Such is life...

Edited March 7, 2015 by [JG2]Ikarus

March 7, 2015

Yep, but all hope is not lost. It's actually possible to get fairly accurate RoC information from having good engine information and using aircraft performance computations based on dimensions and geometry. But sadly, if a plane lacks RoC data, it will typically lack good installed engine power data as well. Only then are you 100% screwed. Such is life...

Agreed 100%

March 7, 2015

Ikarus' timestamp='1425761760' post='241387'] The point of my posting is to explain how to use data, collected by whatever means necessary, to create a chart that is representative of what a time to climb chart is supposed to show, i.e. NOT a time history of a specific flight, but a representative characteristic of an aircraft's performance under certain conditions.

Exactly.

The big issue is you are confusing the purpose of a saw tooth climb with a method to determine climb performance based on what's called "top of the climb". The reason for the saw tooth climb method is speed and convenience. That is why you only climb plus and 500 feet above and below your target altitude.

Saw tooth climbs are designed to check climb performance at single altitude. Think of it as determining a data point. You find Vx, Vy, and climb performance at that single data point. Do that a couple of times to gather data at a few key points and you have enough to check the performance over the whole climb if it agrees with ISA data.

The narrow focus allows for very reasonable return of accuracy with a lot less complicated math.

Top of the Climb method is for determining climb performance to just that....the top of the climb profile. So if you climb to FL350 as the top of the climb, it will tell you the climb performance throughout.

For that to be accurate, you need to do large climb schedules. The higher you climb to the top, the better.

March 7, 2015

You are not wrong JG2Ikarus.....there is just no need to work so hard and I want to be sure you are clear on the purpose of the two techniques.

March 7, 2015

The big issue is you are confusing the purpose of a saw tooth climb with a method to determine climb performance based on what's called "top of the climb".

Big issue? I have no issue, and I am confusing nothing. It seems you have an issue with reading properly or having to be the top of the heap.

The paper you posted is just a less clear, less helpful, and less practical explanation of doing precisely what I typed in my original post.

Edited March 7, 2015 by [JG2]Ikarus

March 7, 2015

Nobody is trying to be top of the heap. Saw tooth climbs look at performance at a single altitude. Top of the climb looks at climb performance throughout a band of altitudes. It is just that simple.

You are probably not confused on that point but there are folks reading this that are confused about it.

Ikarus' timestamp='1425764987' post='241421'] The paper you posted is just a less clear and less helpful explanation of doing precisely what I typed in my original post.

Maybe so but that is because I do not know how much people know and if you assume they do not know, then you get a reputation for talking down to people.

It is Catch 22 brother!!

March 7, 2015

Maybe so but that is because I do not know how much people know and if you assume they do not know, then you get a reputation for talking down to people.

It is Catch 22 brother!!

Fair enough.

Judging from this post and the fact that there are many posts (whole forums even) just like it that still never get it right, I feel it's safe to assume people don't know the math or the process well enough as a group. If they did, these posts wouldn't get drawn out they way they do.

But that's okay! We aren't here to argue about semantics or numbers, we're here to play games and have fun! A computer screen, a desk, and a joystick will NEVER be a real airplane. Best we get over it while we still can.

That said, we should probably save the continuation of this discussion for another day though, or perhaps another thread, as we are really getting off topic now.

Cheers!

Ik

Edited March 7, 2015 by [JG2]Ikarus

March 7, 2015

The big issue is you are confusing the purpose of a saw tooth climb

You may want to re-read what ikarus wrote Crump..

In that I have read it, and it is clear to me that he is not the confused one here..

Based on what ikarus wrote, I think it was clear that he understood the purpose of a saw tooth climb..

Why?

Well because ikarus's description of it is nearly identical to NASA's description of it..

Which should have been clear to you if you had read the NASA document you took the time to provide the link too..

For example..

Here is ikarus's description..

Choose a range of altitudes that you are wanting information for. In practice, I've found 2000-3000 ft bands of altitude gives the best compromise between time invested and error incurred.

Now here is NASA's description..

For the example shown, the time would be measured between 13,000 feet and 17,000 feet altitude. After passing through the upper altitude, the pilot will reduce the power to idle, and again descend to well below the lower end of the test altitude increment.

Does that help?

If not, take a look at the altitude change that ikarus and NASA recommended for high performance aircraft, Below is the example NASA provided

dh/dt = (17,000 ft - 13,000 ft)/(82 sec)

dh/dt = (4000 ft)/(82 sec)

dh/dt = (4000 ft)/(82 sec)

dh/dt = 48.78 ft/sec

dh/dt = 48.78 ft/sec x (60 sec/min)

dh/dt = 2926.83 ft/min

Note both NASA and ikarus selected about the same change in altitude for testing, about 3,000 to 4,000 feet.. Only difference is ikarus referred to it as 'a range of altitudes' and NASA refers to it as 'altitude increment'

What is noteworthy to point out is that neither ikarus nor NASA felt the need to state that the ROC value pertains to the altitude that is in the middle of the of the change in altitude. In the NASA example the altitude that the ROC is associated with is..

Alt = 13,000 ft + (17,000 ft - 13,000 ft)/2

Alt = 13,000 ft + (4000 ft)/2

Alt = 13,000 ft + 2000 ft

Alt = 15,000 ft

Which to me means NASA (and ikarus) assumed that to be understood.. And therefore not necessary to point out.

Your millage may, and typically does vary!

March 7, 2015

he is not confusing it with what your saying he is.

There are a couple of things that intended or not, leave that impression that it is being confused. Now, I don't do "virtual" flight testing.

Ikarus' timestamp='1425751338' post='241319'] If you are flying with a stopwatch, timing your climb, then comparing the results to historical documentation, you are doing it completely wrong.

This statement for example is not correct. Why?

The purpose of doing a sawtooth climb schedule is not to do this:

Ikarus' timestamp='1425751338' post='241319'] Not only is it impossible to replicate a time to height curve (explain how you can have 5000 ft/min climb rate as you pass out of the ground...), it's impractical and is beyond the original intent of what a time to height curve represents.

That is because the time to height curve is derived from the top of the climb method. It is a completely different technique for a completely different goal in mind.

A sawtooth climb schedule is designed to gather performance for performance at a single altitude data point. Not a time to height curve. It represents a way to easily confirm climb data though in a game like IL2.

Because power setting, speed, and configuration remains the same....there is absolutely nothing to integrate in a sawtooth climb method of testing. Infact if you integrated, you would not find the correct Vx or Vy speed of the aircraft.

Ikarus' timestamp='1425751338' post='241319'] The error in the results comes from the specific simplified method of integration I've chosen

You integrate over top of the climb because configuration, power, and speed changes occur.

For example, to climb to FL380 in the jets at work:

1. Gear up

2. V2 +20 flaps up

3. Accelerate to 250KIAS

4. 10,000 feet = Accelerate to 275KIAS

5. FL310 = Maintain Mach .74

And of course our thrust changes with density ratio....

There is a lot of different climb rates represented. Saw tooth is impractical for determining such a large band of altitude. That is not its purpose.

I do applaud Ikarus's effort and have no doubts he does know what he is doing in reducing the data.

There are just two completely different climb testing methods that seem to be intertwined in this thread instead of being very clearly divided as to method and purpose.

Edited March 7, 2015 by Crump

March 7, 2015

Note both NASA and ikarus selected about the same change in altitude for testing,

And that is appropriate......IF your testing a jet that climbs at 300 knots headed for the Flight Levels....

You not testing a jet.....

Your dealing with a prop job that climbs at 140 knots.....

MMM...could knowing that be the difference between rote memorization, understanding and application??

Edited March 7, 2015 by Crump

March 8, 2015

And that is appropriate......IF your testing a jet that climbs at 300 knots headed for the Flight Levels.... You not testing a jet..... Your dealing with a prop job that climbs at 140 knots..... MMM...could knowing that be the difference between rote memorization, understanding and application??

What?

Crump, so you means jets obey different laws of physics than props? Please....

March 8, 2015

There are a couple of things that intended or not, leave that impression that it is being confused. Now, I don't do "virtual" flight testing.

That is your opinion

And you are welcome to it..

But know that I disagree with you

This statement for example is not correct. Why?

The purpose of doing a sawtooth climb schedule is not to do this:

That is because the time to height curve is derived from the top of the climb method. It is a completely different technique for a completely different goal in mind.

I think you misquoted ikarus.. or didn't read what he wrote?

Take a look at what you quoted, i.e.

If you are flying with a stopwatch, timing your climb, then comparing the results to historical documentation, you are doing it completely wrong.

And note the following..

ikarus makes no statement as to the purpose of the saw tooth climbs in that quote

So, I can only assume you misquoted him or misunderstood what he wrote..

A sawtooth climb schedule is designed to gather performance for performance at a single altitude data point. Not a time to height curve.

Agreed..

And at no time did ikarus state the purpose of the sawtooth was to calculate the time to climb data!

Which should have been clear to you in lihgt of the fact that you could NOT quote him saying that!

As ikarus pointed out, he simply used the sawtooth methods to collect ROC values so he could calculate the time to climb values..

It represents a way to easily confirm climb data though in a game like IL2.

Because power setting, speed, and configuration remains the same....there is absolutely nothing to integrate in a sawtooth climb method of testing. Infact if you integrated, you would not find the correct Vx or Vy speed of the aircraft.

See above

There are just two completely different climb testing methods that seem to be intertwined in this thread instead of being very clearly divided as to method and purpose.

Nope, just one used to calculate the other..

And that is appropriate......IF your testing a jet that climbs at 300 knots headed for the Flight Levels....

You not testing a jet.....

Your dealing with a prop job that climbs at 140 knots.....

MMM...could knowing that be the difference between rote memorization, understanding and application??

You may want to read the NASA document that you provided the link to..

In that it does not require the plane to be a JET.. Here is what it actually says..

The altitude increment for the data collection will depend on the airplane's overall performance capability. for highly transient airplanes such as fighters, a fairly large altitude increment is required in order to minimize the sensitivity to time measurements. For transport-type aircraft a smaller altitude increment may be appropriate.

NOTE no where does it say it has to be a JET!

What it does say, in English (read as understanding and not just memorization) means high performance plane data needs more time to 'settle' than low performance planes..

In light of the fact that these are virtual pilots doing the testing, and thus the audience ikarus was talking too, a little more time to 'settle' is a good thing and does not affect the results (within the range ikarus selected) and only gives a less experienced test pilot more time to 'settle'.

Hope that helps!

Edited March 8, 2015 by ACEOFACES

March 8, 2015

Ikarus' timestamp='1425772850' post='241465'] rump, so you means jets obey different laws of physics than props? Please....

Actually they have completely different aircraft performance math.

One is considered to develop constant thrust at a given altitude and changes power with speed while the other develops constant power and changes thrust at a constant altitude with speed.

You should know that.

March 8, 2015

Actually they have completely different aircraft performance math.

One is considered to develop constant thrust at a given altitude and changes power with speed while the other develops constant power and changes thrust at a constant altitude with speed.

You should know that.

I think you misunderstood him Crump..

He said physics, not math

Hope that helps

March 8, 2015

Agreed..

That was some quick editing. You must have actually read the first page of the Nasa document.

March 8, 2015

That was some quick editing. You must have actually read the first page of the Nasa document.

Not sure what your talking about?

But on the bright side, I think I found the source of your confusion..

You said..

Actually they have completely different aircraft performance math.

Apparently you are confusing 'completely different math' with 'completely different parameters & coefficients'

In English, a flight model that is capable of simulating (flight) a plane that can break the sound barrier can be used to simulate (flight) a plane that can NOT break the sound barrier..

Same 'math' (physics)

Just different 'parameters & coefficients' used by the 'math'

Hope that helps!

March 8, 2015

The altitude increment for the data collection will depend on the airplane's overall performance capability

End of discussion and exactly what I said the first time.

Apparently you are confusing 'completely different math' with 'completely different parameters & coefficients'

Keep talking....

March 8, 2015

End of discussion and exactly what I said the first time.

Agreed that should end the discussion with regards to you 'thinking' it only applies to JETs

Keep talking....

Can do! Just good to know my talking is helping you!

Also glad to see that you took the time to actually read the NASA document and realised your mistake! S!

Edited March 8, 2015 by ACEOFACES

March 8, 2015

Nasa says: The altitude increment for the data collection will depend on the airplane's overall performance capability.

Crumpp says:

You not testing a jet.....

Your dealing with a prop job that climbs at 140 knots.....

March 8, 2015

Nice work, Celestiale. You documented your test methodology and your results in (IMHO) a sensible manner. I think Brano did a similar test before, but still it's a relevant and meaningful way of showing discrepancies between real life test data and the simulated flight model we have in the game.

Still it's a commendable effort.

lol @ page 3

March 8, 2015

Funny. These topics about Luftwaffe planes performance is ~40% about "data" and the rest just "Bonfire of the Vanities".

March 8, 2015

Crump,

We already established and agreed that the NASA document did NOT say it only pertains to JETs..

So, not sure what the point of your last post is?

But, I think I found the source of your confusion? Note in your last post, you quoted NASA and yourself.. i.e.

Nasa says: The altitude increment for the data collection will depend on the airplane's overall performance capability.

You not testing a jet.....

Your dealing with a prop job that climbs at 140 knots.....

Take note, you left out portions of the quote (read took it out of context)

Below I provided the same quotes, but included the parts you left out..

The altitude increment for the data collection will depend on the airplane's overall performance capability. for highly transient airplanes such as fighters, a fairly large altitude increment is required in order to minimize the sensitivity to time measurements. For transport-type aircraft a smaller altitude increment may be appropriate.

And that is appropriate......IF your testing a jet that climbs at 300 knots headed for the Flight Levels....

You not testing a jet.....

Your dealing with a prop job that climbs at 140 knots.....

Not sure why you left those parts out?

But, I think we can all agree that including those parts you left out, that it is clear NASA did NOT say large altitude increments are only for JETS..

But, as noted at the top..

We already established that and agreed upon it..

So again, not sure what the point of your last post is?

Isa Speed Testing (Yak And 190 So Far)

Recommended Posts

Crump

GOAT-ACEOFACES

Crump

GOAT-ACEOFACES

=362nd_FS=Ikarus

361fundahl

GOAT-ACEOFACES

=362nd_FS=Ikarus

6./ZG26_Emil

GOAT-ACEOFACES

Crump

=362nd_FS=Ikarus

=362nd_FS=Ikarus

6./ZG26_Emil

=362nd_FS=Ikarus

GOAT-ACEOFACES

=362nd_FS=Ikarus

GOAT-ACEOFACES

Crump

Crump

=362nd_FS=Ikarus

Crump

=362nd_FS=Ikarus

GOAT-ACEOFACES

Crump

Crump

=362nd_FS=Ikarus

GOAT-ACEOFACES

Crump

GOAT-ACEOFACES

Crump

GOAT-ACEOFACES

Crump

GOAT-ACEOFACES

Crump

Chuck_Owl

Sokol1

GOAT-ACEOFACES

Create an account or sign in to comment

Create an account

Sign in

Browse All

Activity