THE CALCLASSIC AIRSCREW CONTROL GAUGES.

The supplied gauges are not 'stand alone'. They are for use with flight dynamics written to match and support their capability. Although creating the supplied example gauges was half of our workload, adapting them for use in your project should be relatively simple. Creating relevant flight dyanmics will be the greater part of your project workload (see later). 



GAUGE NAMING CONVENTION AND SUPPLIED GAUGES.

CP = CONTROLLABLE PITCH PROP -- The user can set the airscrew to any (constant) pitch by *mouse dragging* a '2D slider'. A tooltip discloses 'slider %' and is used by the consumer to match inputs cited within the supplied handling notes.  Gauge example supplied:  quadrant2_CP.xml

This version of the gauge is also used to simulate 3 position and 4 position screws (see much later).

CP_2pos = TWO PITCH PROP --  The most used kind in real life. The user can lock the airscrew to only full fine or full coarse pitch by *mouse clicking* a '2D slider' whose bitmap appearance is (potentially) identical, but which 'snaps to' max and min when clicked. Gauge example supplied:  quadrant2_CP_2pos.xml

AP = GROUND ADJUSTABLE PITCH PROP -- As CP above but pitch can only be varied before flight. In real life only before engine start.  Gauge example supplied:  quadrant2_AP.xml

DP = DUAL PROPULSION -- The user can switch between a CONSTANT SPEED PROP (the default in MSFS) and a CONROLLABLE PITCH PROP. The gauge limits the range of screw pitches available (and thus engine RPM) during CS propulsion. The available higher and lower pitches (and thus higher and lower engine RPM) are accessed only when the user switches to CP, by mouse clicking the relevant text, to toggle the MODE of propulsion. CP then works as defined above. Gauge example supplied:  quadrant2_DP.xml

As listed above, all of the gauges mentioned in this tutorial are distributed as fully working demonstration versions within the supplied CP folder. You will need to vary defined limits etc., to match the engine and airscrew parameters of your project. To aid this process the limits are defined as macros near the top of each gauge that may need to be modified.

<Gauge Name="CP twin quadrant" Version="1.0">
  <Image Name="quadrant2.bmp" UseTransparency="Yes"/>

	<Macro Name="Rated_RPM">2500</Macro> <!-- Max RPM during c/s propulsion -->

Please note that these are only demonstration gauges. All current gauges do what they are required to do. It may be possible to reduce RPM "hunting", etc., with further time and effort, but XML gauge coding experince may be required.  Since this Calclassic technology demonstration pack contains worked examples only for two engine aeroplanes, you may also need to create duplicate code and provide bitmaps suitable for more or fewer engines.

The consumer must add the CP folder you distribute, containing your airscrew control gauges, to their main gauges folder (see need for renaming of gauges below - do NOT distribute altered gauges with the names unchanged!). 

The gauges above (all by Tom Gibson) are restricted only such that you must give credit to Tom Gibson and CalClassic in your text file if you use gauges derived from them.  Do NOT include my email address in any distribution!

Also included are "debug" versions of each gauge for testing purposes, which give a digital display of the current prop pitch (in degrees) and in the tool tip for the individual prop pitch levers they also display the FS RPM lever position in parentheses.


FIVE PART SYSTEM.

The Calclassic airscrew control gauge system is constructed in five parts.  All files other than those listed above can be found in the CalClassic Controllable Pitch Technology Demonstrator (see below).


1.  The controllable_prop_VC.xml file.  

This transparent gauge actually controls the prop pitch, when required (i.e. the Manual Control variable is set to 1).  It does this by constantly changing the FS RPM lever variable so that prop pitch (not RPM) is held constant.  It is always listed in a VC section of the panel.cfg file, since VC sections are always loaded into FS no matter the current view.  If you change the limits in the gauge (or add/subtract engines, etc), you must copy it and rename it with the name of your aircraft (or engine) type in front of the name (e.g. An2T_CP_VC.xml).


2.  The quadrant1_XX.xml file

In each case this is the visible gauge used by the consumer to control A/P, C/P or D/P airscrew behaviour. Your (ecu) bitmap may provide controls only for prop pitch, or may combine the PROP controls with any other quadrant levers.  The supplied throttle and mixture lever code is derived from the default DC-3.  

If the aircraft in question has two position C/P screws, (the most common type -- see Hudson I demo), the gauge will be mouse clickable, but not mouse draggable. That type of gauge can be included visibly within a VC as well as within a '2D panel', or an external pop up window for use with both types of control interface.

Gauges with 2D draggable levers (all other types) must *not* be added to pre existing VCs.  Gauges with 2D draggable levers do not work properly when added to the VC panels themselves. They can be added to a 2D panel or a pop up window for use with a pre existing VC, or both interfaces. The design of future VCs is addressed later in this tutorial.

Again you must rename the gauge with the name of your aircraft (or engine) type in front of the name (e.g. Fw190A_quadrant1_DP.xml). 


3.  The HUDSON_1_RPM_WARNING.xml file.  

This optional gauge works with CP, AP or DP gauges to provide audible and video (text) warning of undersquare running of the engine as well as engine overspeed for any two relevant fuel grades. 

The user selects the grade of AVGAS they intend to load for the next simulation session by mouse clicking the relevant text which remins visible as a reminder (placard). The act of fuel selection alters the gauge engine warning limits to those associated with that Octane rating.

If you include the WARNING gauge in your project you must associate the different engine limits with the different grades of fuel. Some engines were only single fuel, but you may still wish to include the gauge to provide warnings of pilot error. You may choose to create 'engine damage modules' which read variable limit data from that gauge. Damage should only occur at a value somewhat above the warning value. 'Damage modules' are not supplied.

It is normal to run many real aero engines undersquare. The minimum safe MAP will then be depicted by a line, or arc, on the supplied MAP gauge, and / or by reference to BMEP gauge readings. Else only within the supplied handling notes. You should then suppress the undersquare warning horn function.  This can be done by setting the undersquare macro value to 0 at the top of the gauge code. Again this gauge must be ranamed logically to match your project. 


4. AUDIO WARNING GAUGE.

To provide the audible warnings from the Warning Gauge in #3 above, a sound creation gauge is needed.  I have used Doug Dawson's excellent sound gauge, along with Ken Mitchell's sounds from the CalClassic DC-6 panel.  

Note that distribution of the audio components of the WARNING gauge are restricted as follows:

"These gauges are freeware - please do not include them in commercial projects of any kind without my prior consent. Please feel free to use these gauges in any freeware project you wish - you do not need special permission to do so."

Please give Doug credit in any distribution.  (dsd_xml2.zip at flightsim.com)

This gauge requires three things:

1.  The dsd_xml_sound2.gau gauge itself located in the main GAUGES folder
2.  The dc6b_sound.ini file also located in the main GAUGES folder
3.  The KM folder of wav files located in the main SOUND folder

The gauge is added to the VC section of the panel.cfg file:

gauge17=dsd_xml_sound2!dsd_xml_sound2,  2,2,5,5,.\Gauges\dc6b_sound.ini

The sounds are played in the gauge code by loading the wav file number into a variable:

06 (&gt;L:km_xml_sound_id, number) 


5.  ENGINE SELECT GAUGE

Since the gauge in #1 above is *constantly* adjusting prop pitch, multiple keystroke commands (like engine selection) will no longer work.  To avoid this problem I have (by permission) used the gauge by Rob Barendregt that restores the engine select behavior.  Note that distribution of this gauge is restricted as follows:

"If you want to bundle this gauge with your (freeware !!) panel, you may do so AFTER my written permission, provided you include this README file AS-IS, without modification."

Also, you must *not* place this gauge (if included in your distribution) into the main GAUGES folder (I have placed it into the CP folder).  Please respect his wishes - I have.  (rcbse-10.zip at flightsim.com)

If you have multiple opening doors, you may also need to add a door opening gauge to allow those to open properly.


Tom Gibson -- March 2011.



AUTHORING CONTROLLABLE PITCH (C/P) FLIGHT DYNAMICS. 

This FD tutorial is the only FD 'support' for FD authors. I am unable to provide on line support on demand. This tutorial isaimed only at experienced Flight Dynamics developers who already know how to author both 'realistic' f/p propulsion code and 'realistic' c/s propulsion code to match real piston engine and airscrew output as advance ratio (J) varies versus screw efficiency (eta).

This is not an 'air file authoring tutorial'. Anyone who hopes to learn how to code flight dynamics for flight simulation use must first study and understand the relevant real world dynamics textbooks. Only a few reminders of general principles are included below to assist with appropriate sequencing of the sub tasks. 

The supplied Calclassic demonstration of the new flight simulation technology is a demonstration of two pitch controllable pitch aircrews because they were the most common type of c/p screw. This tutorial begins by explaining that specific case in detail, but eventually explains how to also develop adjustable pitch (a/p) screw flight dynamics, 'any pitch' c/p screw flight dynamics, and how to develop propulsion systems with dual mode switching between constant speed (c/s) and controllable pitch (c/p) propulsion dynamics.

Variable pitch (v/p) screws were very rare in real life, but are available by default in FS9 and FSX. This tutorial therefore ignores them, but does not assume that the reader is familiar with coding variable pitch propulsion in MSFS, because developers who only write code for CFS will not be.



STUDY THE CALCLASSIC TECHNOLOGY DEMONSTRATOR:

Download the c/p technology demonstrator from here;

http://www.calclassic.com/files/CP_Demonstrator.zip

Follow the instructions within the install.txt.

Read the relevant forum post.

http://calclassic.proboards.com/index.cgi?board=general&action=display&thread=3662&page=2
 
Then study the supplied on screen handling notes and the supplied mini tutorial before reading this (experienced) FS developer tutorial. The handling notes cite, and the mini tutorial explains, the need for additional handling targets when c/p, a/p or d/p screws are in use. Study the FD code of the technology demonstrator only while reading this tutorial.



RESEARCH your project's AIRCRAFT and ENGINE DATA.

If you cannot find all the data you need, do not pretend you can create advanced flight dynamics for the aircraft or its propulsion system. Some things can be 'fudged', but others cannot.



AUTHOR the HANDLING NOTES.

Reduce all the available research data to the criteria the consumer will actually be required to target during simulation. Create the on screen handling notes *before* coding the flight dynamics to deliver the values in the handling notes that will be used during flight simulation. If any real world handling targets are going to be 'fudged' they need to be fudged before coding flight dynamics to deliver the cited 'fudge'. 

Apart from the usual correctly sequenced phase by phase input and output handling targets, the supplied handling notes for c/p screw simulation must cite;

1) The elevator trim and VG status for Vx at the default weight, (else alternative high power engine overspeed and engine over-torque avoidance criteria).

2) The (multi fuel) MAP limit(s).

3) The (multi fuel) RPM limit(s).

4) The IAS and / or VSI to be employed during the intermediate approach, together with the applicable VG status, which ensure that MAP input, having achieved those operating targets, will always avoid both undersquare running and engine overspeed, when the screws are flipped to FINE PITCH, just before descent from MDA, (often but not always visual circuit pattern altitude). 

You may only be able to discover (1) and (4) via flight testing of release candidate code once you have created it.

Step (1 and 2) will usually resemble;

*************************
Take Off and Obstacle Clearance phase: 

PITCH      = FINE                               <<<<<<<<<<<<
CARB HEAT  = COLD
FLAP       = STAGE 1 (10 degrees)               <<<<<<<<<<<<
TRIM       = 9 degrees (45%) UP (to target Vx)  <<<<<<<<<<<<
LINE UP

BRAKES     = ON
MAP        = 34.5 inches ( 87 Octane Fuel)      <<<<<<<<<<<<
BRAKES     = OFF

,,,,,,,,,,,,,

YOKE       = NEUTRAL
ROTATE     = 90 MIAS  (Vr)
GEAR       = UP 
ACCELERATE = 110 MIAS (Vx)                      <<<<<<<<<<<<<
ACHIEVE    = 200 feet AGL 

Above all local obstacles:

PITCH      = COARSE                             <<<<<<<<<<<<
FLAP       = UP
VSI        = minimal or zero
ACCELERATE = 135 MIAS
COMMENCE   = Climb phase

***************************

Step (4) is more complicated since it must provide handling note solutions for both visual circuits and all types of straight in approaches and in principle for level flight and descending flight. Remember the handling targets you mandate for switching from COARSE to FINE will often need to protect against *both* engine overspeed *and* undersquare running at the moment FINE SCREW PITCH is selected. 

The (too) obvious solution is to call for identical target handling criteria while maintaining the relevant Minimum Descent Altitude (MDA), but provided FINE SCREW PITCH is selected immediately on descending from MDA, having already met the MDA criteria, neither engine overspeed, nor engine undersquare running will occur. 

It is possible to specify an IAS below Vx for either approach case within the supplied handling notes, but that may anyway be unsafe from an aerodynamic perspective in the circuit pattern case, since substantially banked turns will always follow.  You must therefore calculate the flap augmentation to CL required for such turns at Vx, (else your other lower IAS chosen), and impose the requirement for that VG state as a prior VG state within your handling notes, and you must then proceed to code that safe and lawful augmentation of CL from that FLAP stage within your matched FD.

****************************
Approach then Circuit:


''''''''''''

Downwind in visual circuit:


Downwind in visual circuit:

GEAR     = DOWN     <<<<<<<<<<
WHEN IAS < 115 MIAS 
FLAP     = STAGE 2  <<<<<<<<<<
IAS      = 110 MIAS <<<<<<<<<<
PITCH    = FINE     <<<<<<<<<<

'''''''''''''''

****************************

*********************** 
Straight In Approach:

Avoid if possible!


'''''''''''''''

On Descending to MDA:

FLAP  = STAGE 2      <<<<<<<<<<<<
MAP   = do NOT alter 
VSI   = minus 600
UNTIL = MDA
Look for runway lights

Only while maintaining MDA:

IAS = 110 MIAS       <<<<<<<<<<<<<
MAP = as required
Look for runway lights

ONLY IF visual with runway:
On descending:

GEAR  = DOWN         <<<<<<<<<<<<<
PITCH = FINE         <<<<<<<<<<<<<

''''''''''''''''
***********************




NOW CODE THE FLIGHT DYNAMICS SEQUENTIALLY.

The Calclassic c/p demonstrator deliberately uses a CFS2 release from 2004 as its basis (by permission). The demonstration works only within FS9, but the handling note and flight dynamics creation process described herein is valid for CFS2 and all subsequent existing versions of MSFS, (to March 2011), subject to the cited FD variables being coded in the correct location for each version. 


1) CODE THE PROPULSION SYSTEM AS CONSTANT SPEED:

[propeller]

propeller_type = 0

then 'fool' MSFS as below.



2) CODE CRITICAL ALTITUDE to deliver RATED ALTITUDE:


As always code the *critical* altitude of any superchargers to deliver the *rated* output of the reciprocating engines with full throttle, level flight, and FULL COARSE PITCH as the inputs at the rated altitude under ISA conditions.  



3) CODE FULL COARSE PITCH THRUST v Vmax v RPM v horse power:

Because hardly any relevant aircraft have a cross over of their Vmo and Mmo curves all relevant aircraft are likely to have an IAS = Vmax value, limited only by available thrust. The Vmo/Mmo conjunction (in ISA) will probably never define the maximum safe level flight velocity in *relevant* aircraft. In the unlikely event that aeroplanes with relevant propulsion systems have measurable transonic drag (Cdv and / or Cdw) at Vmax at rated altitude you will need to impose those co-efficients and take them into account in addition to the steps which follow.

Thrust efficiency (eta) versus profile drag co-efficient (Cdp) plus induced drag co-efficient (Cdi), must deliver IAS = Vmax using full coarse pitch, at full throttle, at rated power, at rated RPM, at rated altitude, under ISA conditions. 

There are many combinations T/(Dp+Di) which will deliver that result. The only correct solution of the equation is the one that causes profile drag and induced drag to be equal at the real world absolute ceiling where CDp = CDi at Vmd, (neither side of drag curve), which is the only total drag, and combination of drags possible, and only IAS possible, at absolute ceiling, since that is the definition of absolute ceiling. 

The torque slope, the engine  friction slope, and the full coarse thrust slope must then be coded interactively to deliver that real absolute ceiling. You may need to interpolate absolute ceiling from a researched service ceiling.

In other words code the coarsest pitch, as though it were the only pitch, and the screw was f/p, but ignoring all Take Off Distance data, and all initial climb rate data, because those data will be used as the target output only for your full fine pitch code.

The steps above always relate to the RATED output of the engine using the fuel grade specified in the national rating test. METO POWER will be <= RATED POWER and the Go Around (GA) POWER rating is not relevant. With c/p screws the TO rating is always below the GA rating, if indeed a TO rating was ever tested. The GA rating may be specified as 'Sea level' rating.

If relevant EMERGENCY power exceeding GA power must be deployed externally to this process by the usual (gauge based) means and forms no part of step (2) or step (3). Take great care that Vmax employed is RATED Vmax, not (WAR) EMERGENCY Vmax. 



4) CODE FULL FINE PITCH THRUST v Vx v RPM v horse power:

Before you code FINE power and thrust, you must have already determined the lift slope, Cd0 and Oswald efficiency as above. 

It is obviously easier to author 'single fuel' c/p dynamics, but if the engine is really multi fuel, the reference fuel now becomes the highest quality fuel. The slopes of the thermodynamic functions in the air file must proceed to, and be anchored at, their upper ends by their 'best fuel' maxima. 

It is theoretically possible to produce 'single fuel' dynamics for lesser fuels, but research data for needed maxima of thermodynamic slopes, which define each slope, are more likely to be lacking. When the real superior fuel maxima are in place, they define the slopes below, and all inferior maxima, for all inferior grades of fuel, will be present on those thermodynamic slopes.

The FINE pitch code must now be coded to deliver the (multi) fuel inputs versus (multi) fuel power GA outputs at Vx (or usually just above). 

The engine torque slope as far as RATED RPM was set while authoring coarse pitch. If GA RPM exceeds RATED RPM the torque slope versus RPM must now be extended to encompass that higher RPM. The slope must deliver GA power at GA RPM at Vx (or just above) so that the engine produces GA power only at GA RPM only at that chosen IAS. 

The RPM maximum encoded must exceed the highest cited as 'safe' within the supplied handling notes, to allow engine overspeed in the absence of c/s technology. Use the torque slope versus friction slope to control rate of increase of RPM above the cited safe (high power overtorque) maximum. 

If the project gauge author supplies a damage module which causes engine failure it should do so at that higher RPM cited in the FD, not the maximum safe RPM cited in the handling notes. In the absence of such a damage module the FD will poke unrealistic values to the memory stack after pilot error causes RPM to exceed the maximum cited in the FD. You may choose to cause engine failure from within the air file at the cited FD limit instead.

You may choose to employ a fake screw diameter, but if you choose that means to match GA RPM to GA horse power at (or just above) Vx, you will create a feed back loop which destroys the COARSE code at step (3) above. You may nevertheless choose to slowly iterate a fake diameter solution which works for cases (3) and (4). 



5) CODE IN FLIGHT ENGINE SPOOL DOWN:
 
This is no different to coding c/s propulsion. You must code the approach spool down arising from pilot failure to sustain (low approach weight) IAS = Vref at the minimum safe MAP associated with final approach in the supplied handling notes. If that is not known then undersquare running must be assumed to be pilot error. Code only the full fine spool down case as always. MS(C)FS will auto calculate the higher spool down windmill drag = IAS > Vref if the pilot makes an unsafe approach in coarse pitch.

Again you 'may' choose to fake screw diameter to control this parameter, but if you do you will create a feed back loop which destroys steps (3 & 4) above. It follows that although these are ideally sequential steps with no errors in the code of earlier steps manifesting output errors in later steps, you may need to work towards a compliant screw diameter by iteration while coding steps 3 to 5. 

Faking the screw diameter is *not* necessary, but it may save time compared to recoding all the necessary J versus eta curves for the real diameter if you already own copyright to 'nearly compliant' J versus eta curves from another product with different diameter screw and (almost) same screw to engine gearing.

Never proceed to code the steps below until the criteria a to c below have been met and the screw diameter to be used in the FD to deliver a to c is final.



6) CODE TAKE OFF DATA: 

After, 

a) your COARSE code delivers rated power at rated altitude at rated RPM at full throttle, and the output is Vmax using the relevant fuel, and

b) your COARSE code delivers Cdp = Cdi at Vmd at real Absolute Ceiling using the relevant fuel, and

c) your FINE code delivers GA power at Vx at GA RPM using GA MAP for the (possibly different) relevant fuel

Adjust the slope of eta versus J below Vx for the FINE pitch to deliver the real Take Off Roll (TOR) distance to unstick, else the real Take Off Distance (TOD) to 50 feet QFE, else the applicable historical national rating test, for one chosen fuel grade. MS(C)FS will autocalculate (and somewhat miscalculate) TOR and TOD for the other allowable fuels at their allowable MAP and RPM.



7) CODE INITIAL CLIMB RATE (obstacle clearance phase):

If the aircraft in question retains FLAP during obstacle clearance, the easiest way to match initial climb data will be to vary Cdf(oc). Otherwise this must be achieved solely by variation of eta at Vx for the FINE pitch. This will normally require the eta versus J code to permit GA power and GA RPM slightly above Vx in the VG state associated with the obstacle clearance phase.

Again each of those FINE PITCH coding steps is identical to coding any f/p propulsion system, but ignoring all data relating to Vmax at rated altitude and Vmd at absolute ceiling. 



8) CODE the OVERSPEED SLOPES:

This is no different to coding the eta loss slope as TAS exceeds IAS = Vmax, also correctly correlated with the eta loss during over revving of any engine with fixed pitch screw, but of course there are two cases to code for two pitch c/p propulsion. 

Some aircraft had 'cruise props' which lost eta in COARSE pitch above design cruise IAS, at design cruise altitude (in ISA). If so the supplied handling notes should provide the appropriate caution and your FD should provide the early decay of eta.

For the FINE pitch slope Vx, (else the chosen IAS value just above Vx), is treated as Vmax.



9) CODE the 'UNDERSPEED' SLOPES:

This is an odd and complicated concept needed to 'fool' MS(C)FS into treating c/s code as c/p code and is the only part of this tutorial that should 'puzzle' experienced FD authors.

The COARSE pitch slope must deliver very deficient eta at Vx (or just above), while eta of the FINE pitch slope must decay rapidly from Vx (or just above). The eta versus J slopes for full fine and full coarse must be sufficiently 'peaky' and have so little overlap that the Microsoft hard coded Flight Model (FM) never considers any choice other than full fine when full fine is the *logical* choice of two and also never considers any choice other than full coarse when that is the *logical* choice from two. User pitch selection (or mis-selection) using gauges is not relevant to this step. The code must match the *logical* screw pitch selection from a choice of only two.

The eta versus J slopes must be coded so that while the user is employing fine pitch logically, i.e. compliantly as cited in the supplied handling notes, (ideally also as cited in the real handling notes), the eta values of the coarse pitch are so low that the FM will never *interpolate* data from TBL 511 or TBL 512 of the third party air file (the FD). The FM will choose the full fine pitch cited elsewhere in the FD and will never 'look up' other possibilities. 

In other words *at low values of J your coded screw diameter must be 'associated' with a 'logical' pitch lower than the minimum cited in the FD*. The hard coded Microsoft piston engine FM will never attempt interpolation of TBLs 511 and 512 because it 'knows' it must not interpolate beyond the lower end of the look up table *as defined by the max and min pitches cited elsewhere in the FD*. 

[propeller]

Values are those required to deliver c/p screw simulation within FS9 for this engine in this aeroplane.

propeller_type = 0 
propeller_blades=3
gear_reduction_ratio=1.5			
propeller_diameter=11.1
propeller_moi=10				
beta_max=26.4		<<<<<<<<<<<		
beta_min=18	        <<<<<<<<<<<


Here beta_min=18 is not coded because it is the real world value. It is coded because it is the 'logical' pitch at (or just above) Vx. Below Vx the logical pitch is less than 18 degrees, but if the pilot could select that 'logical' pitch for maximum efficiency of power to thrust conversion the engine would overspeed, would produce more than GA power, and would (soon) fail.

Consequently the FM never interpolates from TBL511 or TBL 512 of the FD. The FM knows what value it must look up directly. It always wants to 'search for' a logical value below 18, but by coding 18 as the minimum in the FD we tell the FM that it must not, and the FM already calculated that values above 18 are not 'logical' and not worth searching for. The FM reads values only for 18.0 until IAS is greater than the IAS associated with engine overspeed in the supplied handling notes. 

The gauge author provides the Calclassic engine overspeed warning horn. Transient overspeed (beyond the limit RPM cited in the handling notes, can be remediated by the user, but if user abuse continues until the RPM exceed the limit cited in the FD an engine damage module, or the air file itself, should fail the engine.

Instead at high values of J your coded screw diameter and beta_max must be 'associated' with a 'logical' pitch higher than the maximum cited in your FD so that the FM never interpolates to find a lower pitch than the maximum.

In this context all values of J associated with flight below IAS = Vx are 'low' and all values of J associated with flight beyond IAS = Vx are 'high'. In this context the conversion of IAS = Vx to TAS is assumed to be at 'low' altitude not far above sea level, while conversion of Vmax from IAS to TAS is explicitly at rated altitude in the ISA.

You will normally code only two pitches in TBL 511, but the FM could still interpolate between them. This must be prevented (after screw diameter is final) by choosing max and min pitches which are never associated with intermediate interpolated values while RPM is below the maximum coded in your FD. 

The Hudson I (c/p demo) air file deliberately retains many redundant eta versus J slopes to make this concept clearer. *The FM will never interpolate values from TBL 511 or TBL 512 of the FD until (long after) RPM exceeds max safe cited in the supplied handling notes*, and only when RPM reaches the limit cited in the FD.


**********************************************
Lockheed L.414 Hudson I Pilot's Handling Notes

The two Wright R-1820-G102A Cyclone dual fuel engines ........are rated 900hp at 2300 RPM at 6700 feet (ISA)........Use of 92 Octane military grade fuel .....(it is then permissible to generate 43.5 inches MAP, and up to 2350 RPM, ....... While running on airline grade (87 Octane) AVGAS these engines must instead be throttled to 37.5 inches MAP and 2300 RPM. 

WARNING: Compliance with the relevant MAP limit will not prevent engine overspeed.

WARNING: With military grade fuel (or better) DO NOT EXCEED 2350 RPM. 

WARNING: With airline grade fuel DO NOT EXCEED 2300 RPM.

**********************************************


The coded screw diameter (11.1 feet) requires a pitch lower than the minimum cited (18.0 degrees) to generate 'high' RPM and requires a pitch higher than the maximum cited (26.4 degrees) to generate 'low' RPM. 

Each is explicitly the screw pitch, which at the cited screw diameter, is the one the csu would select in a c/s prop of the same diamter and gearing, with the related RPM lever at max or min RPM, as IAS reaches the target IAS (Vx or Vmax) at the *maximum safe RPM cited in the supplied handling notes* and you must code the max and min pitches accordingly outside TBL 511 and TBL 512.

*With the Cp! gauges installed* the FM can then only choose the cited max and min pitches, provided the pilot restrains RPM below a *the maximum RPM coded in your FD* which is always more than the max safe cited in your handling notes. 

Larger (gross) pilot errors are dealt with via 'damage modules' which fail the engines, (but not in the Calclassic Hudson I demo so that you can watch the progressive engine spool down that occurs in the absence of a damage module to cause sudden spool down to zero after gross pilot error).

The hard coded Microsoft FM 'looks up' only eta versus J for those external max and min pitch values. The FM 'looks' only and 'directly' at those values inside TBL 511/512 of the FD, however many curves are present in those TBLs, and whether or not those max and min pitches are cited pitches in the look up columns of those TBLs.

Note that *only the Thrust created needs to be real* for each current RPM versus each current IAS, in each of the two pitches. The screw diameter and both pitches can be false. 

Since screw diameter and / or screw pitch, can be false at all current IAS and all current RPM, you may need to code eta to be false at current J so that it delivers the real Thrust despite both screw diameter and pitch in use being false; but that is true in all air files. 

Consequently coded eta max at Vx in full fine pitch and / or eta max at Vmax  may be well above, or well below, real eta max for each case. You must simply code the value of eta that delivers the real thrust for that J at the (several) RPM cited in the handling notes you supply (see steps 3 & 4 & 7 far above).



INTERACTION with the CP! GAUGES:

The CP! gauge author can extract the values of the gauge variables he must alter (or delete), engine variant by engine variant, and screw by screw, from the user handling notes you must prepare anyway (see above).

In 'principle' the CP! control gauges are needed only to allow the user to make the compliant binary choice of screw pitch. They do *not* otherwise control screw pitch. If the flight dynamics are true c/p dynamics (as above) they alone constantly impose the max and min pitch with the two position control gauge simply telling MS(C)FS which of those two choices is the current target pitch.  

When the FD are true c/p FD no interpolation or 'correction' from within the gauge code occurs. No parameters develop pendulum motion, and no parameters need to be damped. However in 'practice'.......



LIFEGUARD ROLE:

The Calclassic CP! control gauges also have a 'lifeguard' role. If the FD in use are imperfect the CP! gauges will attempt to impose the control that should emanate from the FD, but parameters will then be seen by consumers to have volatility and the ability of the gauges to damp the volatility becomes a function of the magnitude of the errors within the FD. FD that are not c/p FD in any material sense will usually overwhelm the ability of the CP! gauges to rescue the simulation.



INTERACTION WITH pre existing VC RPM LEVERS:
 
Thus with perfect two position c/p FD (as defined above) pre existing VC animated 'PROP' levers will never exhibit uncommanded motion, but if the gauges are forced to 'jump in and play lifeguard' they will start to WRITE data to the memory stack which will cause motion of any pre existing animated VC PROP levers as the CP! gauges use highly unconventional means to bring the c/p simulation back under control despite the 'sloppy' FD.

Consequently two position screw FD authors have a choice when to 'quit' and that may logically depend on whether the VC has animated PROP levers. If it does they will 'demonstrate' errors in the FD. If it does not 'sloppy' c/p FD may suffice; leaving the CP! gauges to 'jump in and play lifeguard' whenever the 'sloppy' FD lose control of the simulation, without the consumer knowing that they did.

However there is no guarantee that the CP! gauges will manage to damp out FD propulsion code errors so well that other types of oscillation are not induced while the FD have lost control of screw pitch, and also no guarantee that those oscillations will cease after the CP! gauges cause screw pitch to stabilise. 

The CP! control gauges will disguise 'quite sloppy' air file code 'successfully', but whenever the CP! gauges WRITE to the memory stack, visible responsive animated pre existing VC lever motion will occur. The CP! gauges are an imperfect 'kommandogerat' and MSFS does not allow the feed back loop to *pre existing* VC prop levers, intended to seek constant RPM, to be avoided while the CP! gauges are seeking constant screw pitch. *The creators of future VCs for aircraft with two position screw propulsion can avoid that problem* by coding their animated levers to match the criteria within the project CP! gauges.

Below is an example of FS2004 custom CP VC lever code in the makemdl.parts.xml file (tested).  (L:Prop1 Pitch Lever, number) is the position of the lever that controls prop pitch for engine 1.  (L:Prop2 Pitch Lever, number) is the same variable for engine 2.  This example is an infinitely variable lever, but two position, A/P, and other types of levers could also be developed.  Refer to the panel gauges of the various types for ideas of the code changes required in the CallBack_Code section.


<part>
	<name>lever_cp_pitch0</name>
	<animation>
		<parameter>
			<code>
				100 (L:Prop1 Pitch Lever, number) -
			</code>
		</parameter>
	</animation>
	<mouserect>
		<cursor>Hand</cursor>
	   <Tooltip_Text>Prop Pitch 1 %((L:Prop1 Pitch Lever, number))%!d!%%</Tooltip_Text> 
	   <mouse_flags>LeftSingle+LeftDrag</mouse_flags>
    <Callback_Code>
	(M:Event) 'LeftSingle' scmp 0 ==
	if{
	  (M:Y) (&gt;L:MOUSEPOS, number)
	  quit
	}
	(M:Event) 'LeftDrag' scmp 0 ==
	if{
	  (M:Y) (L:MOUSEPOS,number) - -0.5 * (L:Prop1 Pitch Lever, number) + 0 max 100 min (&gt;L:Prop1 Pitch Lever, number)
	  (M:Y) (&gt;L:MOUSEPOS,number)
	}
    </Callback_Code>    
	</mouserect>
</part>



For FSX (untested):


<PartInfo>
	<name>lever_cp_pitch0</name>
 <AnimLength>100</AnimLength>
	<animation>
		<parameter>
			<code>
				100 (L:Prop1 Pitch Lever, number) -
			</code>
		</parameter>
	</animation>
	<mouserect>
		<cursor>Hand</cursor>
	   <TooltipText>Prop Pitch 1 %((L:Prop1 Pitch Lever, number))%!d!%%</TooltipText> 
	   <mouseflags>LeftSingle+LeftDrag</mouseflags>
    <CallbackCode>
	(M:Event) 'LeftSingle' scmp 0 ==
	if{
	  (M:Y) (&gt;L:MOUSEPOS, number)
	  quit
	}
	(M:Event) 'LeftDrag' scmp 0 ==
	if{
	  (M:Y) (L:MOUSEPOS,number) - -0.5 * (L:Prop1 Pitch Lever, number) + 0 max 100 min (&gt;L:Prop1 Pitch Lever, number)
	  (M:Y) (&gt;L:MOUSEPOS,number)
	}
    </CallbackCode>    
	</mouserect>
</PartInfo>


 
WATER VISCOSITY BUG:

The 'water viscosity bug' in MSFS prevents coding of realistic fine pitch code for hydroplanes, or amphibians while being used as hydroplanes. With realistic two position c/p code they will fail to taxi on water! Choose your future c/p and a/p projects carefully. 



THE FUTURE:

Is in your hands. Fourth generation, two controllable position screw technology, is only one of the possibilities now available. There are Calclassic CP! control gauges in this package with prop pitch adjustable only on the ground, c/p and c/s modes available with a mouse click, and 'any position' sliders.  This code can be adapted for 1,2,3 or 4 engines and other control formats, if desired.


DEVELOPING 'MULTI PITCH' SCREW PROPULSION IN MS(C)FS.

The two position screw provides a mathematical certainty of MAX v MIN result which can be delivered solely from within the FD. The CP! gauges could 'play lifeguard' but that can be avoided.

That possibility does not exist when the any pitch CP! SLIDER control gauges are used in your future projects in either a/p, or many pitch c/p, slider mode (see below).  Eventually when any pitch value between full fine and full coarse is demanded by the user the CP! control gauges will WRITE to the memory stack whenever IAS or MAP alter, and will do almost all of the work, but in doing so will cause the animated RPM levers of *pre existing* VCs to develop repeated unwanted responsive motion. 



GROUND ADJUSTABLE PITCH (A/P) SCREWS - AP! slider gauges:

Similar *but different* Calclassic sliders are also provided and can be used to set the pitch of second generation adjustable pitch (a/p) screws before engine start. In practice, (because not all consumers like to start with a cold and dark cockpit), *the relevant AP! gauges prevent change of pitch (only) while the aeroplane is in flight*. 

Data for intermediate pitches are unlikely to be available and so the task becomes one of coding one curve accurately for all values of J and then reshaping each additional curve to be 'parallel crossing over' on either side, simply causing eta to maximise at different J according to screw pitch chosen by the aircraft captain for the entire next flight. 

You will create eta versus J curves for a small number of specific pitches which will be the pitches cited as useful under default defined circumstances in the handling notes you supply. The on screen handling notes will cite 'AP! slider per cent from tooltip'. The 'peakiness' of the few, (maybe only three), chosen eta versus J curves will control how poor the thrust becomes when the user fails to adjust pitch accordingly *before flight*. 

If the FD being redeveloped were previously f/p, and were fully accurate for that single pitch, only 'parallel overlapping curves' either side of the earlier single pitch are required. When starting 'from scratch' that is also the best way to proceed. Create 'relevant' f/p FD as explained in (1) to (8) above and then add 'parallel overlapping curves' either side with eta maximising at different J. Provide relevant user instructions concerning screw pitch choice for different mission profiles within your on screen handling notes.

Do not make the mistake of supposing that existing c/s data for TBL511 and TBL 512 to which you own copyright will suffice. It is very unlikely that they contain realistic values of eta for all values of J since when you authored the FD you will have known that the pitch would alter before extreme values of J were read by the FM. The eta versus J curves within a/p FD must deliver the correct thrust for each pitch, even for extreme values of J, and always all the way to J = 0. 

Ensure your release has the correct type of gauges CP!, else AP!, else DP! matching the FD in use. It may be appropriate to include the CP! (engine overspeed) warning gauge within A/P and D/P releases. Since during simulation of A/P propulsion the AP slider gauge is used only once, and only before flight, it will normally be positioned on its own pop up window.



MANY PITCH and ANY PITCH C/P SCREWS - CP! slider gauges.

About 1938 'many pitch' c/p screws were patented in Germany. If only four pitch the third pitch is then normally associated with Vy and the fourth is the 'feathered' pitch used only after engine failure. You must code the relevant third pitch slope in the same way as coding full fine versus Vx (as above), while instead coding semi fine versus Vy. The reference output data become the time to height data, instead of the initial climb rate data. 

If the screw is four (or more) pitch, the ability to feather should be coded conventionally by the gauge author, using relevant feathering (button) gauges, even though the real pilot or FE used only the prop pitch control lever to set the fixed screw pitch mandated for use after engine failure. If the screw is four pitch you must enable feathering buttons and disable autofeathering within your FD. 

The slider version of the CP! control gauges must be employed with 'many pitch' or with 'any pitch' screws and the supplied on screen handling notes will 'usually' cite the % slider position, *which can be that chosen by the FD author*. By using the 'slider gauges' the FD author is freed from the need to write code that matches a fixed % on the real 'screw pitch control'.

However if the real aeroplane has screw pitch gauges, (and relevant German aircraft will), you will wish to make them read in accordance with the real operating manual. You may wish to write FD code to achieve that or you may instead persuade the project gauge author to incorporate non linearity within the project screw pitch gauges to correct errors in your FD.

Many / any pitch screws were also much produced within the Soviet Bloc after WW2 for use in engines from 1000 BHP downwards, but Soviet engine efficiency targeting practices differed. Access to the relevant operations manual is necessary to locate the standard RPM or per cent RPM targets. The relevant number of pitch slopes must then be coded to maximise eta at the J associated with each Soviet operating target.

This simply replicates the process of maximising eta versus J for each different cited absolute RPM, in each phase of the supplied handling notes, when the screw is instead c/s. Starting from scratch this process is no more time consuming to code. It may also involve flexure of the torque slope at the RPM generated when eta maximises, and so is really just a different way of referencing an identical procedure. 

Most relevant German operating manuals cited (steady state) screw pitch targets instead of per cent or absolute RPM, and relevant German cockpits had screw pitch gauges. Soviet cockpits usually have no screw pitch gauge because manually selected constant screw pitch is treated as an input, not an output, in relevant Soviet Bloc cockpits. Those are just on screen handling note authoring issues, by reduction from the real operating manuals, (see introductory text far above).

Do not confuse fourth generation many pitch c/p screws, which cause RPM to vary continuously with IAS and altitude density, with fifth generation constant speed screws which prevent that and cause screw pitch to vary continuously instead to demand a supplied handling note specified RPM directly, and which will not vary with IAS or altitude density.


DEVELOPING FD to support DUAL MODE C/P and C/S PROPULSION.

More advanced German propulsion systems had two states which were 'auto' and 'manual' within a more complex analogue engine control computer (kommandogerat). Manual means 'by hand'. 

Any real 'kommandogerat' (engine control computer) had many other functions, but for the purposes of this tutorial you only need to understand the engine management computer's ability to hold screw pitch constant (manual mode) while RPM varied, else to hold RPM constant while screw pitch varied (auto mode). Manual kommandogerat is the only mode of operation of relevant Soviet era engines up to 1000hp.

When replicating superior German dual mode propulsion systems a 'drehzahl' thumb rocker switch with a visible 'prop % tooltip' can replace the CP! slider. The same tooltip % will deliver the same input to the 'kommandogerat', but your gauge / VC author will need to develop that alternate means of input from the Calclassic % slider. A 'drehzahl thumb rocker', (study the singular thrust lever of a real Fw 190), is a convenient way of avoiding unwanted VC lever motion during manual use of the dual mode drehzahl control.


DP! SLIDER GAUGES.

The Calclassic developer pack also provides DUAL PROPULSION SLIDER gauges. These resemble CP! slider gauges, but have mouse clickable text selection of c/p propulsion (manualkommadogerat) or c/s propulsion (autokommandogerat). Although mostly associated with German combat aircraft of all kinds many other combat aircraft, and some non combat aircraft, had dual mode propulsion. The Curtiss P-40 for instance.

You will need access to the real operating manuals of dual mode propulsion aircraft to reduce those real manuals to relevant MSFS on screen handling notes before authoring relevant FD. During DP! simulation sessions the DP! gauges are the 'kommandogerat' and will control screw pitch, else engine RPM, according to mode selected (by mouse click of the gauge text). 

Your job as the FD author is to encode 'realistic' c/s propulsion for 'part' of the screw beta range AND to create MIN and MAX code as explained above for two pitch c/p propulsion. 

The project gauge author must alter the max and min beta limits for c/s propulsion within the Calclassic supplied Kommandogerat = DP! gauge to match the range of beta values for which you supplied multiple overlapping c/s J v eta curves. Thus when the consumer selects c/p = manual by mouse click of the DP! gauge text they will be selecting the max and min beta curves you created while the slider is in its maximum and minimum positions.

Thus the pilot can constrain the screw to very course pitch to reduce engine RPM in steep dives, to prevent engine overspeed. Conversely aeroplane overspeed is prevented (or not) by the FULL COARSE PITCH overspeed slope you coded at STEP 8 (far above). 

The consumer can instead constrain the screw to very low pitch to increase engine RPM at any MAP, for instance to produce WEP at Vx during a scramble mission. In many propulsion systems Emergency Power requires Emergency engine RPM to generate that emergency power. That may be incompatible with autokommandogerat. 

It is often necessary to revert propulsion control to manual, turning off the engine control computer, to obtain emergency power via emergency RPM that auto (protected mode) never allows. You must understand the specific real control system to code that real control system. The DP! gauges are the kommandogerat. They set (by variation of their code) the auto limits of that specific kommandogerat and provide the means to turn auto OFF to deliver manual = EMERGENCY criteria via screw pitches above and below the auto (protected mode) maxima. Some specific dual systems may have allowed 'manual excess' in only one direction. That is for you to research. 

The real systems did not (usually) allow reversion from manual to auto while RPM were outside the auto (C/S) limits. the supplied gauges replicate that. The user must control MAP and IAS so that RPM is within the csu (C/S) limits before switching to autokommandogerat. (constant speed = constant RPM mode). 

Assuming you need to write both c/p max and min curves you will proceed exactly as for a two position screw as explained above, having already provided the  J v eta curves within a narrower pitch band compatible with auto = protected = c/s propulsion. Max and Min pitch are controlled by the FD as always, but the project gauge author can and should vary the outer c/p limits within the Calclassic DP! code, since that reduces 'hunting'. He will anyway have set the specific and narrower C/S limits for that engine and screw.



RELEASED INTO THE WILD.

Whilst Calclassic 'may' release propliners with a/p and 'any pitch' propulsion in the future there is no specific intention to do so, in part because those technologies barely relate to 'propliners' used within the United States during the Classic era of aviation history. 

The zip file which contains this tutorial also contains all the necessary types of generic gauge for future use mentioned above, but it is up to FD developers to create the FD they need to be usable. They are not a 'bolt on' solution for existing FD.

The means have been published and provided as freeware by Calclassic so that others who are interested in the relevant phase of aviation history, aircraft with relevant roles, and the relevant national engine and aircrew control systems, can take up the challenge to incorporate those realities into MS(C)FS. 

FSAviator March 2011.






 

