Spitfire Mk IIa performance tests - Patch 1.07.18301
 

Hello gentleman!

Is with a great honor to anoucce the new performance tests.

Hope you enjoy this tests!


Settings:

No winds, full fuel tanks, full loadout, pilot with parachute, radiator open, summer conditions, takeoff from Manston.

--------

Spitfire Ia , Spitfire Ia 100oct and hurris will come soon! We are working hard to colect all datas. ;)

=AN=Felipe

Great job !!!

Looking forward to see this when I'm back at my PC, Felipe. My stupid iPad can't open .zip files. :(

I post the same file in ATAG forum, but in PDF, only PDF without ZIP.

:D

What format opens ?

PDF works great on an iPad! Thanks to both if you can post it unzipped. =AN= rocks! :grin:

No problem Snapper! If you still have some trouble send me an email, ill send the file direct to you ok?

felipe.borkowski@hotmail.com

cya!

Follow the link to the .pdf !!

http://www.4shared.com/office/As0Dlh...itfire_Mk.html

As i expected CloD Spitfire MKIIa still way too slow both at deck and FTH. Still wrong power engine settings - mainfold pressure (boost) and RPMs. The same situation like with other RAF fighters. 109 regarding power engine settings is much better and realistic modeled - it should be only faster ab. 20 kph at the low alts then now.

I think with actuall FM and performacne of these planes there is no sense to make such detailed test and comparision before 1C will fix it and make it in much more accurate and historical way - if they ever do these.

S! Kwiatek,

I work on a automatic excel sheet, so its no problem for us do this detailed tests. I agree with you and i hope the developers check this out, i know them have more programs to do this like scrips but the precision of this test should be arround +-3mph so its not a unaccurate teste, this is our present performance in cliffs of dover.

If the developers dont use this for consult and one more parameter of comparasion dont mind, we can use this to ask for a more realistc FM and charge to do this.

Thx for your post! ;)

I think thats why its important to show the devs what we find. This is a beta test after all and we don't know how far they have gone in testing the FMs or how far they intend to go with FM development and what their target data is.

Felipe, it would be nice if you could include the historical data alongside the test data for an immediate comparison. And the source reference of course to fend off any arguments. What do you set yout altimeter to? I adjust mine for "true height" as pos.z from for Point3d pos = me.Place().Pos(); (converted to feet for the Hurri). Default 1000mb is something like 100 ft out at SL and around 200ft at 20,000 ft, not a lot but...

Sure Klem, ill use the real tests too in comparasion. So the altimeter was setted to 985mb 0ft at manston airfield, then i start to run the tests, so its about -400ft if we do by your technics, no winds and other things, if you are talking about that i do this way :D

thx klem

Hi Felipe,

Manston elevation is around 144 ft and Tangmere ~40 feet. I checked the Altimeter error two ways. I deliberately ditched in the sea and checked the output file for ditched altitude reading I_Altitude (when it hit the water) and also the 'True Height' or PosHeight from this:
Point3d pos = me.Place().Pos();
PosLongitudinal = pos.x;
PosLateral = pos.y;
PosHeight_m = pos.z
PosHeight_ft = PosHeight_m * 3.2808399
That indicated that the altimeter should be set to 992Mb.

Of course for low flying its the Sea level you want which in theory can change with the tides but I don't think that's modelled.

I also use HudLog to display some parameters on screen all the time including Altimeter Altitude and True Height so I can easily set the Altimeter. The frustrating thing is that I just loaded the mission again and found that it has changed to 995mb and I don't know why! Anyway its only something like 100 ft difference so no big deal with the FMs being as far off as they are. Funny thing is that if I ignore that and set it to 992 I seem to be about right over the sea low level.

Why dont you guys set altimeter to 1013? this is what will give you standard pressure altitude which is what most charted data is based on, theres not much need to actualy test at sea level, simply start the testing at 1000ft and the data can be projected for the last 1000ft to sea level.

Manstons surveyed elevation was 150ft during wartime and tides are never factored, an elevation is based on mean sea level i.e. the average of all tide heights.

are you guys using the density altitude conversion for the tests?

?????!!!!???

Don't pull tht hairs too much... You'll need it when getting older !

Because the CoD environment doesn't seem to be set to 1013. In any case the True Airspeeds are calculated in the script using IAS, Altitude and the CoD environment data (apparent pressures and temperatures) including Density Altitude:

//calculate TrueAirspeeds and MACH
//Pressure Altitude P_alt=Ind_Alt+145442.2*(1- (alt_set/1013.25)^0.190261)
Pressure_Alt = I_Altitude+145442.2*(1- Math.Pow((C_AltimeterPinion/1013.25),0.190261));
//Density altitude (D_Alt) = P_Alt +(StdTemp0/.0019812)*(1-(StdTemp0/OAT)^0.2349690) ; = P_Alt +(273.15/.0019812)*(1-(273.15/OAT)^0.2349690)
Density_Alt = Pressure_Alt + 137870.9872804361 * (1 - Math.Pow((273.15 / Z_AmbientAirTemperature),0.2349690));
//TrueAirspeed_mph = CS/(1-6.8755856*10^-6 * ''DA'')^2.12794 (NB assume IAS = CS)
TrueAirspeed_mph = I_VelocityIAS / Math.Pow((1 - 6.8755856 * Math.Pow(10, -6) * Density_Alt), 2.12794);
TrueAirspeed_kph = TrueAirspeed_mph / 0.621371192;
TrueAirspeed_kt = TrueAirspeed_mph / 0.868976242;
//Mach Number (M) = TAS/CS; CS = sound speed= 38.967854*sqrt(T+273.15) where T is the OAT in celsius; TAS is true airspeed in knots.
MACH = TrueAirspeed_kt / (38.967854 * Math.Sqrt(Z_AmbientAirTemperature + 273.15));

There is no CoD C# parameter for Pressure to set the Altimeter by so I have to measure it and/or set it by reference to True Height. I am assuming 'True Height' is from Mean Sea Level. Can't think what else it would be. I set the Altimeter to read as near as possible to True Height when on the runway so I won't hit the sea on low level tests and I'll have near-correct Altitude reading on he Altimeter. Having said that, at a setting of 992mb its about 4 feet out at sea level but its about 2,000 feet out at 20,000 ft. something wrong somewhere. I don't thionk it matters at the moment as he performance is so far off but I'll include some mB vs Altitude error checks after the next patch.

EDIT: Did some tests.
Max Alt setting available is 1045mB. At True Height 20,000 ft, Alt reading ~19,900. Closest I could get.
Alt setting 1045mB at TH 15,000ft, Alt reading ~15,500. Alt setting for correct TH reading 1027mB
Alt setting 1027mB at TH 10,000ft, Alt reading ~10,500. Alt setting for correct TH reading 1007mB
Alt setting 1007mB at TH 5,000ft, Alt reading ~5,800. Alt setting for correct TH reading 998mB

Am I missing something?

At 992mb at 19C, the density altitude at sea level is 1194 feet.

If the atmosphere is correct, then standing at sea level is the same as being at 1200 feet altitude on a standard day to the airplane.

Your altimeter is just a barometer and measures pressure. It will only show some 554 feet!!!

All the altimeter sees is pressure while the aircraft sees density. Test flying is done at pressure altitude and performance calculated according to density altitude.

Set the ALTIMETER to 29.92inHg or 1013Mb. That is your altitude for starting your performance calculations.

Well that would skip the first calculation of Pressure Altitude from indicated altitude and altimeter setting and I might try that but I don't see how that would change the resulting TAS.

I'm not a test pilot, I'm just doing the Maths and it took me a while to get my head around how to do these tests. I did it that way so I could fly at/very near sea level on the altimeter although as bongodriver says I could just project the 0ft value.

I'm not sure what your trying to say other than to collect the readings in a different way that skips one calculation step.

Do you think my results will be incorrect for some reason? See above fornulae drawn from
http://williams.best.vwh.net/avform.htm#Mach
and my Hurricane results
http://forum.1cpublishing.eu/showthread.php?t=33135

Problem?

Hello .. know you are a pilot in real life, as I also am .... I wonder CLOD simulated the density of air?

When we tested only noted the IAS and TAS data calculated by default by this site http://www.csgnetwork.com/tasinfocalc.html

We are open to good tips please!

Thanks

It won't but it will make it easier when doing the testing.

Are you doing these offline or online?

If online, have someone take up an airplane with an OAT gauge and record the temperature.

If off line, try a plane with an OAT at the same location as you test. Record the temperature at various altitudes. To make sure the temps are consistant, I would re-enter the same location/mission a few times to make sure the sea level OAT remains the same.

One thought, has anyone checked to make sure the weathering slider does not effect performance? Aircraft will lose performance over time as the engine/propeller wears as well as the finish.

klem,
Don't waste your time with a charlatan, generally you are doing just fine with the tests.

There is plenty of good testing manuals available freely in the net, IMHO the best one is the USAF Flight Test Engineering Handbook, available from Scribd:

http://www.scribd.com/doc/19204672/U...ering-Handbook

It's a large file, over 700 pages but worth to read. As example the correct way to test the critical altitude can found from the section 2.5 (p. 382->).

Its no harder. The data is collected and the TAS calculated, all automatically, as described.

I am doing the tests 'online' through my own server in Multiplayer... Server
Its possible that this may produce different results to a separately connected online server, all I can do is, say, fly a few level speed tests under the same settings on ATAG and see what that does.

Temps at Altitudes (same mB setting) are consistent across the various aircraft tests. These represent several exits and entries to the sim.

The Temperature I am using is generated from the game parameter:
/// [Misc.: Ambient Temperature]
/// <para>Indicates air temperature around machine's location, in K.</para>
/// </summary>
Z_AmbientAirTemperature
There is another available which is
/// [Inst: Ambient Temperature]
/// <para>Returns ambient temperature gauge reading.</para>
/// </summary>
I_AmbientTemp
.... but that appears to be the instrument drive value so I use Z_AmbientAirTemperature

According to the manual the Weathering Slider has no effect on performance.

For my full data set see and run my Performance mission linked in my previous post.

The Weathering slider is labelled "Visual weathering" it doesn't affect performance. Historical performance degradation (wear and tear) was a feature that CLOD was going to have but has at present been dropped or not yet implemented.

it's difficult to tell if the game models density altitude well, to be honest we would need the game to give us more control over atmospheric variables, we know they have used a standard adiabatic lapse rate and the atmosphere is more or less ISA + 10, so we know that the density altitude should be approx 1200 feet more than pressure altitude.
so the tests should be done using 1013 on the altimeter to give pressure altitude and then for each altitude band you test at you know that ISA + 10 means your density altitude is 1200 feet more
i.e 2000 foot pressure altitude at ISA + 10 = 3200 density altitude

the density altitude is what the game test data should be being compared against real life data, if things start to match up then we have an indication of wether the FM's and atmosphere modelling is correct.

Klem,

That assumes that everything is correct in the atmosphere model.

You can cross check it by setting pressure altitude on the altimeter. If the values are different, they you know something is up.

Thanks for that info bongodriver, I believe I have made the mistake of plotting my Hurricane results against indicated altitude instead of bringing them to a common playing field of Density Alltitude.

Apologies to you Felipe for diverting your Thread onto "Principles of Performance Measurement" but it may prove useful to you for gathering data for the Spitfire IIa once I have straightened out the script in my Performance.mis.

So, bongodiver, just to be sure I have got this:

1. I believe my TAS calculations (formulas in earlier post) will still be correct as they use indicated altitude and altimeter setting to arrive at Pressure Altitude and then OAT to arrive at Density Altitude?
2. I the take calculated Density Altitudes and plot TAS against those?

If Yes to both that actually makes the performance figures worse because on my Hurricane chart with DA being higher than Indicated Altitude (SL temp was 16.9C) the results get pushed to the right. Again apologies to Felipe but I'm attaching those Hurricane results (Indicated Alt and DA) as an excercise in my understanding of performance measurement.

I will re-run the tests using 1013mB setting and see how that turns out but I think the results should be the same as the DA chart attached. Then I'll correct my Hurricane Thread post.

In a nutshell Klem yes I think you got it.

as long as your calculations arrive at a density altitude, I prefer 'rule of thumb' calculations over the boffins pages of calculations personally, they may be very slightly less accurate but for the effort it takes.........

heres another one that might be usefull......

TAS increases by 2% over IAS per 1000' and this is also affected by density altitude, this has the surprising effect of increasing the TAS when temparatures are high, we normally associate hight temps with a degradation in performance.

eg.

lets say cruising at pressure alt of 10,000' at 300kts with ISA +10

2% 300kts per 1000' = 60 kts so TAS@ 10,000' = 360 kts in standard conditions.

ISA +10 = 1200' higher density altitude so 10,000' pressure alt = 11,200' density altitude which in turn means another 2% TAS increase = 366kts TAS

OK, well the calculations take place in the script so its not a problem but I'll run those "2%" estimates alongside them just for the hell of it. Hopefully find time this coming weekend.

btw I'm assuming those old A&AEE TAS charts used density altitude as well otherwise the whole measurement process is pointless. They do say 'on a standard day'.

The data in flight manuals is almost certainly always going to be based on standard conditions (ISA) it basically sets the benchmark.
when conditions are exactly ISA then assume density and pressure altitude are the same, density altitude increases with deviations from ISA in the positive temparature range and likewise reduces in colder temps.

bottom line is when you test in actual conditions then assume the density altitude and compare against the charted data.

Yes it will be a great help in any future testing. It is silly to even discuss airplane performance without knowing the atmospheric conditions.

You can tell if the game is modeling denisty altitude by looking at the FTH. If the FTH matches standard day conditions, the atmospheric model is not correct.

Hi crumpp.

If the terrain is to scale in ClOD, you could try 'time vs distance' over varying alts to confirm atmospheric change effects on TAS.

Hi Peril,

Good to see you. Hope they get the P-40 in the game soon, LOL.

That is a really good idea. You could even do T vs D in cardinal directions to check wind modeling, confirm the PEC, and TAS.

I think so.. In that I found and error in your Density Altitude calculation

See the following REVIEW of your Java code.

Before we do that, I took the liberty of re-wording the formulas you used from Williams site, i.e.

http://williams.best.vwh.net/avform.htm#Altimetry

I also added more detailed definitions all in all with the goal of making them easier to read and follow

Now lets review your Java implementation of Williams formulas

Here is the Java code you want to use

Where:
If you plan on doing any testing above 36Kft than you will want to adjust T_std as follows

Where:
Thus no need to check for height above 65kft in that I don't think the X-15 is in the game.. Yet! Or if the sequal includes the Bf-109K-4 with the uber FM you might have to add that check! ;)

SUMMARY
I don't know if I would use Williams formulas.. I have some concerns with how he handles some of the units, but since you were using his formulas I thought it best to review those formulas. Also not sure if you can use Z_AmbientAirTemperature directly in that it is not realitve to I_Altitude.. And as you know small temp differences can have a big effect on Density Altitude calculations, so hopefully these are small differences. Might be better of using the ISA Standard Temp formulas adjusted for temp.

Hope this helps! S!

PS see attached where I did a quick ROC test and ploted the different altitudes

OK I get the Constant versus T_std/TLR error, I made the mistake of taking it directly from his example

OK
I don't but I might build that into the code in case anyone else wants to use it.

The Z_AmbeintAirTemperature appears to be the OAT at the altitude, it decreases with alt at around 0.0021C/ft

It does, thanks. Also learning from Robo that the BCO doesn't work unless I wiggle the throttle.

Roger that..

But my point is it is NOT realitive to 'I_Altitude'..

As far as I can tell it is realitive to 'Z_AltitudeAGL' and/or 'Z_AltitudeMSL'.

In short, the Z_AmbeintAirTemperature value your using may be the OAT realitive to another 'altitude' and not the one the plane is currently at..

For an example of which I speak, look at the TIME TO CLIMB picture I posted

Note at the higher altitudes (around 17.5Kft) the "Z" altitudes are quite different (higher) from the indicated, pressure and density.. Thus in and around that area when you use Z_AmbeintAirTemperature (OAT) your getting the temperature 'realitive' to the "Z" altitudes and not the OAT realitive to indicated, pressure, and density. How big of an error that will introduce.. Not sure have not calcualed it yet, but knowing how a little temperature difference can have a big effect on the calcuation of density altitude one should take pause.

Again, not 100% sure yet, need to test that to prove it to myself! I just wanted to bring it up should you come across it while testing

OK, well there is the parameter I_AmbientTemp. William's example calls it Actual Temperature. It looks as though that is what he means, actual emperature as measured in the aircraft environment, "the outside air temperature (OAT) or static air temperature (SAT) refers to the temperature of the air around an aircraft".

Now, regarding:
Density_Alt = Pressure_Alt + (T_std/TLR) * (1 - Math.Pow((T_std / I_AmbientAirTemperature),0.2349690));
(now with I_AmbientAirTemperature)

Where:
T_std = 288.15 - Alt_ind × TLR
TLR = 0.0065

and

if ( height < tropopause ) then
TLR = 6.49(°C/1,000m) = 1.98(°C/1,000ft) = 3.56(°F)/1,000ft
else
TLR = -56.5(°C) = 216.65(°K)

I have two questions.

1. TLR is a rate so presumably below the Tropopause the Temperature Lapse is - Alt_Ind x TLR but above the Tropopause the Temperature Lapse is simply 56.5C ?
and similarly......
2. Within the DA calc, T_Std/TLR would appear to calculate an altitude. Does it hold good above the Tropopause where the lapse rate is zero or should I be capping T_Std at 288.15 - 56.5 = 231.65K once T_Std/TLR hits 56.5?

EDIT: Sorry, ref Q.2, I meant should I replace T_Std/TLR with some other expression above the Tropopause??

EDIT2: Think I've got it

if ( 15 - Pressure_Alt_ft*0.0019812 < -56.5)
{
TropAlt = PressureAlt - 56.5/0.0019812
TempStd = 288.15 - 56.5;
Density_Alt_ft = Pressure_Alt_ft + (TempStd/0.0019812 + TropAlt) * (1 - Math.Pow((TempStd / I_AmbientAirTemperature),0.2349690));
else
TempLapse= Pressure_Alt_ft*0.0019812;
TempStd = 288.15 - Templapse;
Density_Alt_ft = Pressure_Alt_ft + (TempStd/0.0019812) * (1 - Math.Pow((TempStd / I_AmbientAirTemperature),0.2349690));
}
TempStd = 288.15 - TempLapse;
Density_Alt_ft = Pressure_Alt_ft + (TempStd/0.0019812) * (1 - Math.Pow((TempStd / I_AmbientAirTemperature),0.2349690));

Ah yes, I forgot about that one!

I just don't recall if every plane had one? I noticed that when a plane does not have a guage for a said "I" value that said value is not aval to read/log.

But we can use that value and log it along with the "Z" value (which is allways active) you were using to see if they are the same, or if they diverage at some point (alt). If they don't than I was worring for nuttin and we can continue to use the "Z" value.

Ok lets see if I have two answers! ;)

Exactally!

Take a look at any standard atmosphere table/graph and you will see that is indeed the case

Let me look at your code a bit.. and ill get back to ya!

So, one answer, one pending! ;)

My bad..

When checking for the tropopause, i.e.

We have to adjust the whole T_std equation, not the the TLR!

Note I had this

Which is wrong!

What we want to do is this

Where

Just got home and thought I would do a quick ROC TTC test..

In this test I set the Altimeter_set to 1025mB..

And note in the TTC you can see the I_Altitude changes (red) as I change mB.

Anyway, not a formal test, so don't draw any conclusions from these results.

OK, couple of things.

Rethinking what I said about:

if ( 15 - Pressure_Alt_ft*0.0019812 < -56.5) <--- determines the Tropopause altitude
{
TropAlt = PressureAlt - 56.5/0.0019812 <--- calculates altitude element above Tropopause
TempStd = 288.15 - 56.5;
Density_Alt_ft = Pressure_Alt_ft + (TempStd/0.0019812 + TropAlt) * (1 - Math.Pow((TempStd / I_AmbientAirTemperature),0.2349690));
else
TempLapse= Pressure_Alt_ft*0.0019812;
TempStd = 288.15 - Templapse;
Density_Alt_ft = Pressure_Alt_ft + (TempStd/0.0019812) * (1 - Math.Pow((TempStd / I_AmbientAirTemperature),0.2349690));
}
TempStd = 288.15 - TempLapse;
Density_Alt_ft = Pressure_Alt_ft + (TempStd/0.0019812) * (1 - Math.Pow((TempStd / I_AmbientAirTemperature),0.2349690));

I'm not sure about the part:
Density_Alt_ft = Pressure_Alt_ft + (TempStd/0.0019812 + TropAlt) * (1 - Math.Pow((TempStd / I_AmbientAirTemperature),0.2349690));

TempStd/0.0019812 is the correction of Pressure_Alt_ft within the Troposphere, beyond which there is no/negligible further Temperature Lapse so no correction seems to be required for that so I think the original formula applies, just
Density_Alt_ft = Pressure_Alt_ft + (TempStd/0.0019812) * (1 - Math.Pow((TempStd / I_AmbientAirTemperature),0.2349690));


EDIT 2: OK, regarding I_AmbientAirTemp, as you say it is only present where the gauge is fitted and it isn't in the Spitfire or Hurricane and returns zero.

so, how about this to get I_AmbientAirTemperature ?
if (I_Altitude / Z_AltitudeMSL_m > 2.5) //is I_Altitude in feet?
{
Z_TempLapse = (Z_AmbientAirTemp - 288.15) / Z_AltitudeMSL_ft;
else
Z_TempLapse = (Z_AmbientAirTemp - 288.15) / Z_AltitudeMSL_m;
}
I_AmbientAirTemperature = I_Altitude * Z_TempLapse;


Also, what are you using to create your charts? I tried plotting the Y axis as Altitude (as is often done for these tests) but Excel threw a wobbly when the Level Speeds or ROC reversed with altitude.

PS Further apologies to Felipe for turning his Spitfire thread into a general "Aircraft Performance Measurement" thread but I think it is just about On Topic :)

Hey klem

Im at work right now.. But Ill take a look at your Java code when I get home tonight.. I don't want to rush it and make a silly mistake like I did with T_slr vs TLR

As for the units, The variables that start with 'I_' as in indicated as in the cockpit guages will change betwen IMPERIAL and SI units depending on the country of origin. For example, when test the Spit the I_Altitude will display 'feet' but when testing the 109 it will display 'meters'. Where as the 'Z_' values are allways in SI units.

As for what I use to graph, I use matlab. As for excel, you can flip the axis, simply right-mouse-click on the graph and select 'Source Data' at which point it will display the data for the X and Y axis.. You just have to flip the X and Y sources.. You can type it in, which can be messy, or cut-in-paste swap, or simply click on the button and drag-n-drop the columns of data.. Which can be messy if you have alot of data. See attached for excel examples

Hey klem..

Have not had a chance to work on it yet, got home friday night and the girl friend had 'other ideas' as to how I was going to spend my time this weekend! I am hoping to get some time tonight to work on it! S!

Hey klem

Sorry this reply took so long.. I have been busy with some of my own stuff..

On that note I still have not writen the C# code for you yet, but wanted to share with you my matlab code, i.e.

I you have not used matlab, know that it does some things under the hood. The big thing being arrays, if you have an array, and you want to do stuff with it, you don't have to do the indexing for example, say we have an array called 'dog' that I want to apply an offset to, and create a new array called 'cat'. In matlab all you have to do is the following:

Where as in most other languages you would have to do the indexing yourself, i.e.

Same goes for mul or div

The period before the * and / means apply this to each value (each index), instead of the sum of the array

Feel free to contact me if you have any questions

PS still debating on wether we can use the ingame temp, or not, ill keep you posted

You'll understand if I don't take up matlab, C# is enough of a challenge!

Those formulas are generally what I am using.

btw I assume our TLR_Cpm is for altitude in feet not metres (TLR_Cpf?).

The problem we have for calculating Density Altitude is that there is no OAT indicator. Then there is the question of whether Z_AmbientTemp relates to the cockpit altitude.

I did calculate a lapse rate from Z_Temp and Z_AltMSL and assuming 288.15 at SL but that gave daft results.

So I have assumed Z_AmbientTemp as OAT. I crashed at SL and it returned 290.1K or ~17C. At 15000ft it gave 260.2, a lapse rate of 0.0019933 for the CoD environment so I guess its OK for our purposes.