Flight Model (FM) Testing Spitfire Mk.Ia 100 oct v1.10.20332 Beta
 

Flight Model (FM) Testing Spitfire Mk.Ia 100 oct v1.10.20332 Beta

CONFIGURATION:
The following Top Speed per Altitude (TSPA) test was performed starting with a full fuel load and ammo load (no bombs) and the radiators/cowlings are set to full open (worst case).

PROCEDURE:
The top speed is tested at each of the following altitudes:

The test begins with an air start near sea level. At each altitude the plane flies for a distance of 15,000 meters (9.32 miles) before climbing to the next test altitude. Note at SL and max altitude there may be some 'pilot error' associated with the data (spikes), therefore you may have to ignore the 'spikes' in the data at these two extremes and visually extend the graphs using the data above and/or below the spike. I am working on C# code to do this automatically, but it is not finished.

During the flight all pertinent data is logged using a C# script. The TAS and altitude (Z_VelocityTAS & Z_AltitudeMSL) data is than graphed (see attached). The graph only plots the max TAS value per altitude. If you would like to viewed/inspected all the TAS values you can do so at my web site http://www.flightsimtesting.com/.

NOTE at my site you can compare one in-game plan to in-game plane, or an in-game plane to one of the many real world data sets that are uploaded at my web site. This was done to make it easier to see how well the in-game plane test data matches the real world test data. You can also change the units SI to imperial, and save any graph displayed by simply right-mouse-clicking on the graph and saving it as an image to your PC.

I am also in the process of allowing you to upload your own in-game and/or real world test data at my web site, after which you will be able to graph and compare data via my web site.

SPECIAL THANKS TO:
FST for double checking my C# script file
FG28_Kodiak for all his help with C# scripts
Ataros for all his help with C# scripts

can i ask how on earth you get over 340mph at 17000 in spit 100 octane? that is on par with real life specs

I am sure I can only get 320mph, thats with no fuel and radiator at 35% too. It currently only goes as fast as the hurricane 100 octane which can do 320mph (accurate)

Was the test done at 3000 RPM and +6.25 boost?

Yes.. I made a mistake during flying and forgot to enable the boost.. So in essance this test is limited to +6 boost.. So Ill have to re-do this test.

One thing to note, the speed matches that of the 87oct Spitfire Mk.1a, expect at higher altitudes. Two 'see' what I am talking about, goto my website and plot the Spitfire Mk.Ia vs. the Spitfire Mk.Ia 100 oct.

Keep in mind that I am using the internal (Z_) C# script values of TAS and Altitude, which dont have any of the 'issues' associated with the indicated (I_) values used to drive the cockpit guages.

Bingo...even RWorld Brit's "indicated" under reported

BTW AoA, how do you get in and out undetected, are you using the B6 monitor stealth mode

Hi AoA.

I'm afraid the IL-2 Cliffs of Dover link on your website won't work for me at the moment (11:45am UK 15/10/2021)

I'm surprised you managed to do the 3000rpm/+6.25lbs test, the engine runs roughly for me at full rpm and full boost at 10,000 ft and 20,000 ft in my tests so I gave up until they fix the problem. It is almost certainly the case at other altitudes too although 1,000 and 2,000ft were ok, returning 270 and 273mph Z_TAS after about 5 mins, BCO override giving 302 and 309mph. btw It was only carrying 65% fuel/5845lbs, a little under N3171 trials at 6050lbs (my error left over from the Hurricane tests).

We were experiencing similar engine problems on ATAG last night at various altitudes and power settings. Are you using your own in-game server? Could you post your mission and .cs file?

EDIT: btw Z_AltitudeMSL is true altitude above SL but is not representative of the Density altitude, e.g. in my 2000 feet test with indicated altitude 1658ft (Alt Baro set to 1013) I get Z_Altitude_MSL 1227ft, Pressure altitude 1664 due to CoD SL pressure (which should be close to Indicated but we cant set Baro to 1013.25) and Density altitude, the effective atmospheric altitude adjusted for temperature (or Standard Day), 2000 ft. At D.A. 10,000ft (well, 10,013) Z_Altitude_MSL is 9930ft and at D.A 19926 (close to 20,000) Z_Altitude_MSL is 21,367. There's a crossover around 12k.

Strange.. Granted it does take awhile to load after you click on the 'Il-2 CoD' tab.. So give it a few min before clicking on it again.

Strange.. Might have something to do with the way I did the test, as I pointed out to Banks, I messed up and need to re-do this test

No just a single mission

Here is a link

http://forum.1cpublishing.eu/showthread.php?t=34964

I think you and others will find it very handy when doing top speed per altitude tests.. In that I put ~10 miles worth of 'FLASHING RING' at each of the test altitudes, which in turn makes it a lot easier to maintain the altitude, in that you get a 'visual' feedback and basically all you have to do is fly through the FLASHING RINGS

Yup! That is why I use it over the others! ;)

What kind of defviation do you get flying through the rings? I try to stay within 10-20 feet of altitude.

But that means you can't compare it with historical data because Z_Altitude_MSL is the 'tape measure' altitude not the Standard Day or "meteorological" altitude.

EDIT: AoA, I wonder if the rough running is an on-line problem only? Would be interested to hear how you get on if you retry the SpitMkIa/100oct offlinre at altitude.

None.. I have flown many tests and have yet to S myself while flying! ;)

J/K!

The altitude of the rings are rock solid, as expected, and I can keep the gunsite on the center ring pretty well.. I have not looked at the data as to what my vairation of the alt was.. Not that it is not importnat, only that I know there will be some variation. What I am working on is a 'filter' that will not accept a TAS value as part of the MAX TAS per altitude if the ROC value is above a certain level.. That is to say if your are diving.. and pickup speed due to a shallow dive, the ROC value will be NOT be ZERO.. Thus if any TAS values that occur when the ROC is above a certain level will not be considered valid and thus not part of the MAS TAS graph.. Doing this will automatically remove any bad TAS values due to bad flying (i.e. not level flight).

OK :)

Yes ROC is not right.
You might like to think about:
Z_Accel_x = cur_Plane.getParameter(part.ParameterTypes.Z_Overl oad, 0);
Z_Accel_y = cur_Plane.getParameter(part.ParameterTypes.Z_Overl oad, 1);
Z_Accel_z = cur_Plane.getParameter(part.ParameterTypes.Z_Overl oad, 2);

x = accleration fore/aft
y = accleration left/right
z = accleration up/down

z lets you know if you are accelerating up or down (changing height). I 'filter' by eyeball when assessing the records I get back, looking for 1.0, +/- about 0.03 to get a stable string of records. I also cross check for stable altitude +/- a few feet but within about 20 feet of the test altitude and for the IAS or TAS staying at best speed for good level flight. Its surprising how quickly it settles down, maybe 5 minutes, and how stable and predictable the returns are even over minor changes in height and Z_Accel_z ('G'). Makes it easy to see where speed is changing and why and to pick out the most appropriate result.

Salute

I did two hours of tests of the Spit IA and Spit IA 100 octane, less systematic to be sure, but it was online on the ATAG server.

I found all Merlin equipped aircraft had some degree of misfiring and cutting out at certain altitudes, with the effect happening more frequently the higher the aircraft climbed. This became more pronounced when maneuvering accompanied the climb. The effect came on at lower boost levels when the rpm was high, and conversely required higher boost at lower rpms. It was also more likely to happen when you increased the throttle, (boost control) or rpm, (selected finer pitch) rapidly. The effect begins with small stutters, you can see your rpm gauge kick, then as you increase the rpm or boost, the effect escalates into full on misfiring and cutting out. This effect happened without any overheating, and no damage resulted. After doing nearly an hour of testing in a Spit IA 100 octane, with probably 10 minutes worth of misfiring/backfiring, I was able to drop down to below 10,000 ft and use 2800 rpm and +6 1/4 boost to shoot down a 109.

This effect is entirely unhistorical, the carbureted Merlin had no tendency to misfire or backfire at neutral or positive G's, and it was more capable of sustaining high rpms and full throttle at higher altitudes than it was down low. (because the max. boost which could be obtained was lower, especially over critical altitude)

The effect began as low as 8000 ft as far as I could determine, I got misfiring and cutting out of the engine of the Spit IA 100 Oct at 2900 rpm and +6 1/4 boost at that altitude. As mentioned, this occurred even when the engine temperatures were at low levels, 85 degrees C.

I found the Spitfire IA 100 octane was the worst aircraft for this effect, and it was prevented from getting over much more than 23,000 ft in a climb. At that altitude, it could not manage more than +0 boost/3000 rpm without misfiring. It was necessary to increase rpms to 3000 in order to register any kind of climb at that altitude.

Here are some samples of altitudes/boost levels/rpms when I got the onset of misfiring in the Spit IA 100 octane:

14,500 ft: +5 boost 2700 rpm

16,500 ft: +4 boost 2700 rpm

18,500 ft: +3 1/2 2700 rpm

20,000 ft: +2 boost 2700 rpm

21,000 ft: +1 boost 3000 rpm (as I got higher, I found reducing boost and increasing rpm was the best solution for max. climb)

22,000 ft: +1/2 boost 3000 rpm

The Hurricanes were much less likely to see this effect, in my experience, the only occasion I found the 100 octane Rotol Hurricane had this happen was at 2800 rpm/+6 1/4 boost at 16,500 ft, although I was not looking for the effect at the time, I had thought it was limited to the Spits, was just flying combat.

There was also another anomaly with the Merlins, in that there is a pronounced tendency to overheat sooner at higher altitudes. Flying at 2700 rpm/+1 boost at Sea level will see the engine operating at 85 C, but at 21,000 ft, using exactly the same boost and rpm and with the same radiator settings, temperatures will be up at 95 degrees. As anyone knows, temperature should be more easily controlled at higher altitudes, not the opposite.

I have been told others are getting different results, and it may be the installation, although my own wingman was also getting the effect, and many others have reported it.

As it stands, the Spitfires especially are still crippled for combat over approx. 12,000 ft, and do not achieve their historical climbs or speeds.

I plan to do some more testing tonight after verifying my Steam installation, deleting the cache and re-downloading the latest patch.

Yes you are right all the merlins apart from the Spit 1 two stage prop have overheating issues when higher.

this engine cutting out bug is ridiculous.

+1

Good Report.

Salute

I retested online on ATAG tonight after first verifying my Steam install to the official patch, then downloading a new copy of the new patch and installing it after deleting cache.

I still got the misfiring and engine shudders in both the Hurricane I 100 octane and Spitfire IA 100 octane, with the Spitfire's onset being approx. 8-9000 ft, and the Hurricane at about 14-15,000.

Contrary to my previous impression, this time after more experimentation I've decided the issue is brought on mostly by the level of boost used, and that rpm has very little to do with it, except at very high altitudes.

No way to prove it, but I suspect this has something to do with the negative G cutout modelling and is also related to the modelled brief engine stutters and coughs which happen at any altitude when you increase throttle rapidly on the Merlins. My impression is the negative G is somehow activated by the sudden yaw of the aircraft, or perhaps the torque of the engine when throttle is suddenly opened, or at higher altitudes when higher throttle is used.

In any case, it shouldn't be characteristic of the Merlin.

+1. You need to put this in bug thread

That doesn't seem to be correct, at higher altitude though the air is much colder, at the same time it's also much less dense. Without air to contact with, the radiator may find it more difficult to transfer heat. High altitude engines typically required larger coolers for that reason.

Generally, overheating seems to have been changed accross the sim, 109Es for example are now seem to overheat very easily and are much more difficult to keep in line. Their cooling system can't handle engine heat at historical settings.

+1

Nice work, Buzzsaw.

Not right? I guess that depends on your point of view, in either case, using the ROC velocity or accelerations to filter the MAX TAS is better than using neither! ;) The only down side to using the accelerations is they are never zero, so you will have to do some testing and thinking about what values of acceleration to use as the pass fail.. Where as the velocity is a little more intuitive, granted, the velocity alone has issues, in that a transition from the pos limit to the neg limit through zero could result in a bad MAX TAS being called good, where as using the acceleration would not be fooled by such a transition.

The eyeball method is great when you have just a few of your own tests to review.. But it starts to become a very big task once the number of tests increases or you have to start reviewing the results of other peoples tests.. Which is something I use to do for people 10+ years ago when this sort of testing was done with IL-2.. But these days I am just too busy to do that, which is why it is my goal is to provide tools that anyone can to use that automate such tedious process and to make it more standardized.

Nice work Buzz!

Hey, if your interested, I have an OFFLINE single mission you can use for level speed testing here..

http://forum.1cpublishing.eu/showthread.php?t=34964

Note I have placed ~10 miles worth of RED FLASHING RINGS at each test altitudes to make it easier to fly level..

I am also working on a C# script file for that mission to log the data as you fly that provides you a heads up display (HUD) of your altitude, velocity, ROC, etc. Let me know if your interested in testing out that script

Klem has already done this for everyone to download.
The red rings are a good idea.

What we really need is someone to write an autopilot that intercepts the directx inputs to control the aircraft. Surely the 46 one could be adapted, I'm afraid I don't know enough about directx.

56RAF_phoenix

Actually FST did it before klem

klem is using an older version of FST's, that klem made some changes too..

I have been working with FST to come up with a newer version with a standard file format that will match the format my website can accept

Thanks

It is something I came up with years ago back when I was doing IL-2 testing, only back than there were no RING to use, I had to create rings using LIGHTS

Sad things is the autopilot used with IL-2 used DeviceLink to get and set values.. And as far as I can tell the C# script only gets values.. That is to say there is no way to set values.. I have been looking into some other ways to set values, but that project is on the back burner right now.. Just too busy right now

I don't think there's any need to use DeviceLink to set values, one could generate a proxy DLL that intercepts DirectInput calls (assuming they've not switched to Xinput) and replaces the joystick values with your own to fly the aircraft. Though this is a "dangerous" thing to do because keyloggers do the same.

The existing C# script could be used to extract the values needed to fly the 'plane. Even if we can't get attitude values, you could calculate trajectories from the position data.

56RAF_phoenix

Need?

No, no need

Sorry if I gave you that impression.

I only brought up the way DeviceLink works with IL-2 is because you brought up the autopilot program for IL-2 46, which 'does' make use of DeviceLink to interface with the game..

As for a proxy DLL, no 'need' (pun intended) in that there are several virtual joystick programs/device drivers/etc out there that the autopilot program could use to send (set) commands to fly the plane

Which is what I am doing now in the C# script..

In that many of the same variables I am logging during flight are needed as feedback to an autopilot program

You can get attitude values.. and more!

Neat thing about the C# over the old DeviceLink is we have many Many MANY more varialbes to 'get' than we had with DeviceLink in IL-2

Only down side is we have none to 'set' which is needed to have an exteranl autopilot fly the plane

In summary

You could write an autopilot program for CoD using (in) the C# script with calls to the virtual joystick..

That would provide all the capabilites that DeviceLink provided and more!

We are in complete agreement.

However, you should be aware I did most of my programming in FORTRAN IV. But I have used almost every language under the sun from Algol68 to SNOBOL4. Just not on PCs (well, my first "PC" was an Altair 8800B using an Intel 8080, later I had a Personal Cray!)

56RAF_phoenix

Ah, thanks, I couldn't remember who's 'Black Box' script that was that I found many months ago. Credit to FST then. I played around with it, added some more parameters, worked in 'Standard Day', set it so the data could be stopped and started with the gunsight switch, etc. The Excel analysis was a logical extension of gathering the data in .csv format.

If they ever fix the (online?)Merlin problems I'll go back to testing but its a bit of a drag especially when its pointless.

Incidentally the two sets of low level TAS figures I did manage to get were:
3000 RPM +6.25lbs boost:
1000 feet, 270mph vs A&AEE's 286mph
2000 feet, 273mph vs A&AEE's 291mph

3000RPM +12lbs boost
1000 feet, 302mph vs A&AEE's 318
2000 feet, 309mph vs A&AEE's 322mph

All at Density Altitudes or 'Standard Day'. Incidentally, Z_Altitude_MSL was 194 feet and 1227 feet at those Density Altitudes.