Sign in to follow this  
Guest _FSAviator

Manipulating aircraft FDE parameters from an XML gauge ???

Recommended Posts

Hi,Does anyone know if it is possible to (temporarily) change aircraft parameters, such as thrust or weight, directly from an XML gauge ?Reason: I'm working on a freeware catapult launcher, and obviously need to emulate a fast accelleration at takeoff.But I can't find any K:Events that could help me to accomplish this.I have made something based on the SLEW behaviour in FS (setting a high speed when you exit SLEW mode and the A/c is off the ground) but I don't find that realistic enough.I know that it is possible to do this using the FSUIPC programming interface (like the original ArrestorCables program is probably doing) but that type of programming is not (yet ?) part of my skillset :-)Thanks, Rob

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Greetings Rob,I suspect the reason that no one has answered is a feeling that the

Share this post


Link to post
Share on other sites

Thanks indeed for the insight. The timing is amazing, as I had been thinking about undertaking just such a project. Doug Dawson

Share this post


Link to post
Share on other sites

Hi "FSAviator",First of all, thanks very much for your clear and extensive comments.I understand and respect your opinion towards not using FDE parameters to simulate functions like this catapult takeoff and cabletrap landing.On the other hand, as long as FS doesn't really support these types of functions, I believe ANY solution will have it's drawbacks, being FDE-based, but also wind-based, or otherwise. So I'll still be considering my options :-)Regards, Rob

Share this post


Link to post
Share on other sites

I have not had time to respond further until today. I will try to explain what I think you need to do to advance from the status quo, since I believe that what you propose is to some extent already available for many aircraft, but not much used for reasons which may become apparent. Provided the aircraft in question has one or more supercompressed piston engines the panel author can already add 'Mopar' Mike Wagner's FS8/9 'WEP switch'. The FDE author then controls the additional energy and duration added by the emergency fluid injection as though the energy is being injected by a catapult. This will overheat and over-torque the engine, so this method is not compatible with FDE and gauge combinations that have realistic failure criteria embedded. It also requires false declaration of WEP power obtained via emergency fluid injection. This is not a major objection in MSFS, though it certainly would be in CFS online combat usage. You would need to create an invisible gauge that disables 'catapult WEP' in flight. AFAIK there is no similar 'WEP switch' solution for turbine engines (see bottom of post). The optimum turbine engine FDE cludge is therefore to assign four engines to a single engined aircraft and have an invisible gauge instantly switch on 2 to 4 only IF throttle > n% and switch them off IF NOT on ground OR throttle < 100%. The bogus engines are co-located with the real engine(s). However even quadrupling the applied energy will not simulate the applied energy from a catapult shot and the end user will still have to slew the wind. They will just get some additional acceleration after full power lever advance when ON GROUND. Any solution which uses on board power (piston or turbine) to simulate the catapult thrust may theoretically be 'aurally incompatible' with any existing sound.cfg. If turbine engines do not have reheat which needs to be coded realistically the FDE author can add catapult energy as huge afterburner thrust, but this will add very little acceleration at low velocity, and it may consume huge quantities of the real fuel. Inexperienced users may believe that the afterburner is real and this method would again be unacceptable to the CFS community so you would need an invisible gauge which detects reheat and cancels it IF NOT ON GROUND.Any existing fuel dump/refuel gauges can be used to manipulate fuel state and therefore aircraft mass before and after launch. This would facilitate manipulation of pre launch mass and post launch mass as well as providing further functional realism when in close formation with an AI tanker. Alas FS9 does not support AI towline holding patterns. You might add code to all the tank gauges to make them point to full for the first five minute after engine start whilst you manipulate the aircraft mass (and induced drag).In addition the FDE author can include an extra bogus set of flaps to provide huge lift augmentation. This would get the aircraft airborne at very low IAS but then the user has to accelerate to normal flight speed before retracting the bogus lift augmenting devices. You would need to develop an invisible gauge to reject retraction below Vx. You would also need to disable the bogus flaps via an invisible gauge when throttle < 100% so that they cannot be deployed inadvertently on approach or after landing. However none of these FDE and gauge cludges ensure a safe catapult shot regardless of wind over the deck, so they don't really solve the problem. Remember unless the wind is slewed by the end user they may be trying to launch with 'negative IAS' and temporary manipulation of mass, thrust, drag and even lift cannot solve that problem.Doug, thanks for responding. I look forward to an FSUIPC wind vector based solution as it should work for all aircraft, including all pre existing FDE. It would be nice if a smoothed post launch correction of wind velocity and shift of heading to the values in the overridden weather could be incorporated. May I ask you if you know of a gauge which uses FSUIPC as the interface to augment turbine trust, or turbine torque, for a time limited period in response to water methanol injection, and if not whether you think these are feasible projects which you might also undertake in the future? Catapult launching aside their relevance to functional realism is considerable.FSAviator

Share this post


Link to post
Share on other sites

Smoothing the wind direction should not present a problem. Simply a matter of calculating the difference and correcting it gradually over the desired period of time. As panel updates occur several times per second, there will be no sudden changes.I'm not aware of any gauges currently available to augment turbine thrust or torque. Had a look at the SDK for FSUIPC. There are memory offsets documented for Engine Torque, Turbine Engine Max Torque Fraction, as well as Propeller Thrust and Jet Thrust (Pete's notes indicate that turboprops have both.) For reciprocating engines, fuel/air mass ratio is available. Some experimentation will be required to determine which of these values can be overridden in a meaningful way and which must be manipulated indirectly.Actually creating a gauge to apply the override is pretty straightforward. The biggest issue will be deciding the value required. The use of an optional parameter on the panel.cfg line for the gauge would allow experimentation with a number of values to determine which was most appropriate. I could certainly look at projects like this...If you haven't already done so, you might want to have a look at the SDK to see what is available:http://www.schiratti.com/dowson.htmlDoug

Share this post


Link to post
Share on other sites

I have downloaded and read the latest SDK. If it lists the offset as 'OK' in FS9 does that mean that it can be written to as well as read? If so then all the necessary variables appear to be controllable through FSUIPC. Having seen what is available 'all' should not be many.<>Agreed, but I will address what I see as the optimum solution in this post. Fortunately I think you may be over estimating the complexity of what I am proposing.I have not flown aircraft with water/meth injection in real life. I understand the usage in piston engines, but I am less clear about turbines. Ideally a plain words description of the process should come from someone with real world experience of controlling the output of jet and turboprop engines in wet and dry states. I am only approaching this goal from the point of view of an FDE author. Wet/Dry TOGA case seems reasonably clear, but does anyone reading this understand the usage of water/meth to create WEP in turbojet fighters? Can anyone explain whether it has any value at high altitude when full throttle / dry does not overtemp the turbine anyway? This is more of a CFS issue anyway and a poor simulation of water meth in pure jets is available as weak afterburner without using FSUIPC.Potentially there is one module required for turbojets and turbofans combined, and another for turboprops. In all cases there is mass to decrement. Do you agree that no one knows how to access the payload offsets and that water/meth defined as payload therefore cannot be decremented?It appears that total mass can nevertheless be manipulated independently of fuel usage. Is that correct? That is not my preferred solution anyway.If the water/meth tank were defined as a fuel tank by the FDE author in the aircraft.cfg he could create the real CG and inertia offset variables, and they could vary in real time. The 64000 USD question is can you prevent the 'fuel tank' with water in it being selected (as fuel) by the user and by FS9? Can you use your 'fuel' dump gauge code be rewritten to access just the tank with water in it and 'dump' just the water/meth when the switch is ON?Payloads defined as fuel tanks, which cannot be used as fuel, but with full simulation of mass, CG and inertia effects, coded by the FDE author, which can be 'dumped', have many more uses than water/meth simulation if you can figure out how to prevent selection of that (those) tank(s). This would be a big bonus.<>I am assuming this will NOT be the job of the module, or the module writer. I only expect the module to read input values provided by the FDE author, either from a water_meth.cfg or better still from the panel.cfg as you suggest. I don't expect you to calculate the values. I am only hoping you can figure out how to read them and impose them on FS9. Whether it can be done from a panel.cfg presumably depends on how many values?Potentially we have (for each engine);% change of torque % change of thrustOR (much better)% change of max torque% change of max thrustAND Possibly% change of JPT (but not needed for turboprops)AND Possibly for the aircraft current massbut this last is superfluous if the water/meth is defined in the aircraft.cfg as a fuel tank and is decremented by a dump gauge nested within the water/meth switch which is the solution I would like to reach.If so a turboprop module would ideally have only one variable (per engine) i.e. Turbine Engine Max Torque FractionThis appears to be possible, but implies that the gauge is limiting torque (is active) while the water meth switch is OFF not augmenting whilst ON since the ability to increment above 100% looks impossible. FDE author simply declares wet torque limit in the FDE and your module passes the % decrement for dry from the panel.cfg.I propose to manipulate only max torque in turboprops since the slightly (w_m) augmented thrust from the turboprop exhaust adds little power at take off speeds. Don't worry the % decrement values are not hard to research compared to a lot of FDE data and I expect you to leave them to the FDE author.Is max thrust fraction available? I could not see it. If it is then pure jets should be just as easy - BUT you may need some defined temperature cases (ISA assumed) in the gauge, or module, for WEP use at high altitude in fighters (see above). Not required for TOGA case. Many jet panels will need decremented JPT with water/meth ON. This could be post output gauge display code not requiring FSUIPC so manipulation of the turbine temperatures INSIDE FS9 is not really an issue at all if max thrust and max torque can be controlled directly.Does this mean that the module normally only sends data when the switch moves? Does it have to modify max values every cycle, or do max values persist until changed? This is a complication since if the process is decrementing the max from wet max to dry max with the switch OFF your module must be active whenever the engines are running and may need to send a decrement max message as each engine fires up. Not an issue if it sends every cycle.Not sure where a water_meth.cfg would have to go. I suppose the user would have to copy such a cfg from the aircraft folder into the FS9 root folder (overwriting) on a per aircraft basis, so panel.cfg is obviously superior.For testing use a turbo prop and see if you can impose 10% lower max torque when dry. Set up a bogus fuel tank at CoG with say 50 USG defined as content and see if you can dump content from it, and no others, when the water/meth switch is ON using a nested dump gauge. See if you can prevent FS9 selecting the water tank as fuel. Else see if you can force it to use that tank last? Presence of existing cross feed gauges may cause a problem? Such gauges may need more tank specific code for compatibility with the module? One 'problem' is that this method would NOT allow huge over declaration (by the end user using Notepad) for the CV catapult case, which is where we started. I don't think FSUIPC can push thrust and or torque fractions beyond 100% of the value declared as max in the FDE. Do you agree?FSAviator

Share this post


Link to post
Share on other sites

The 'OK' in the FS9 column means that the value is present at the offset listed. Not all of these values can be written to. If FS is constantly updating them, based on other values, then the value written can be immediately lost. I say 'can be' because I have successfully implemented a catapult by writing to a groundspeed offset, which should, in theory be constantly updated... This was what I was really getting at with the reference to experimentation.Payloads can be changed by FSUIPC. See offsets 13FC and 1400 in the SDK. All we have to do is agree on a payload station number and the capacity of the tank. My fuel dump gauge affects all tanks simply to keep it generic. There is a separate block of code for each tank. It is a simple matter to use this same procedure to reduce the capacity of a payload station. To directly answer your question, yes, FSUIPC can effectively prevent the use of fuel in specific tanks. Yes, this would have the effect of allowing their use as a distribution of mass within the airframe. Payload stations could also be used to this effect. Defining the actual airframe weight at some value less than actual, with the difference being defined as 'cargo' may at first seem odd, but why not try it? The overall effect on mass will be the same, but you should be able to manipulate handling characteristics to your advantage.More than one parameter can be specified on the panel.cfg line. Paramters are in fact read in as a single block of text, which must be converted to numbers by internal gauge code. This could either be done be checking for commas or other separators (probably easier for the user to understand) or by using the binary coded decimal approach.You might want to post a message on Pete's forum to check with him directly about the potential availability of values which you don't see on the list. He is not averse to adding new memory offsets, if the data can be located.http://forums.simflight.com/viewforum.php?f=54Torque - While working on the fuel dump gauge, I discovered that it is certainly possible to increment values over previously defined limits - ie, I ended up with fuel tanks containing 102% of capacity. Furthermore, there is no reason that a gauge cannot be written that will actually be functional when the switch is 'off' All one needs do is change the condition in the 'if' statement fromif (switch == 1) toif (switch == 0)It's that easy. Functions can be set to occur only when the switch is triggered or to happen all the time. There is much flexibility here.I will investigate the turboprop torque fraction. BTW, I now have a working prototype of the catapult that got this whole discussion going. If you were to send me your e-mail address, either by private forum message, or by e-mail (my address is in my user profile) I could send it to you. I would appreciate your comments.Best regards,Doug Dawson

Share this post


Link to post
Share on other sites

"AFAIK there is no similar 'WEP switch' solution for turbine engines" I set it in an FS2K2 AC but no KB switch would work to set it. I think I even checked the long list of key combinations. Virtually all turbine powerplants have that capacity for 'WEP' and even more power. Full throttle typically sets way too much thrust for even a few seconds. Just advance the throttle so N1 or Torque is at an appropriate 'WEP' rating and you have it. Same for turbocharged engines. One can set the maximum MP higher than the 5 minute TO rating. All 'WEP' in CFS does it let it go even higher for a limited time. Set the 'Damage' slider at less than maximum and more time is available before over G crashes an AC. I assume the same applies to over thrust, or over torque. One could also set the turboprop maximum torque (in aircraft.cft) higher than normal, that would require 100% torque on the panel gauge to be set lower than normal but one could run at say 110% without getting damage in FS. Ron

Share this post


Link to post
Share on other sites

As a follow up to my previous post...I have determined that one can indeed write to both Engine Torque Percentage and to Turbine Engine Max Torque Fraction. Both of these values are in fact continually updated by FS, but will accept an IPC written value. This value will be overridden by the calculated value on the next update, so it is a matter of calculating the desired value and continually writing it via FSUIPC. I'm sure this can be done.Doug

Share this post


Link to post
Share on other sites

Thank you for the further explanation. The fact that I am not a programmer limits my comprehension of what is possible via either gauge code or via FSUIPC. I am still struggling to understand exactly what FSUIPC can and cannot do, but the situation is much clearer now. It seems that all the variables an FDE author might wish to manipulate have known offsets. The issue appears to be whether particular imposed values persist. I confess to missing the fact that FSUIPC now has the ability to manipulate payloads in real time. I now concur that the water/meth should be a station_load.n of defined mass included by the FDE author. The module documentation will need to specify the value of n. It needs to be a fairly high value and not conflict with any new load station protocols which have evolved, or may evolve as designers learn to make greater use of this feature. I suspect there are a fairly large number of MSFS end users who would like to have panels with say up to ten 'live bomb switches' which are each linked with say station_load.41 to station_load.50. If they exist I have missed those too.<>That is one of the areas which I struggle with as a non programmer. Since the FSUIPC SDK says;<>I assumed that the internal value could not be incremented beyond the FDE declared value. Maybe its just a case of never trusting SDKs, whoever wrote them.Setting the highest available max torque value in the flight dynamics and decrementing it if water/meth injection has not been selected seems logical anyway if the catapult, rail and hydroplane take off issues can be resolved by other means.Your update noted with pleasure.<>I will contact you tomorrow. If you have not already done so, maybe you could also ask Rob to comment since I rather hijacked his thread, and his opinion on the catapult launching module, and any desirable modifications, may be more relevant than mine?FSAviator

Share this post


Link to post
Share on other sites

Ron said, << Just advance the throttle so N1 or Torque is at an appropriate 'WEP' rating and you have it. Same for turbocharged engines.>>Obviously I agree completely for turbocharged engines, (see thread about enabling multiple power limits in FS8/9), but I have avoided any discussion of turboprops in that other thread because what I have said there, and Ron has repeated here, does not generically apply to turboprops, it only applies to a few. The main problem is that there is no such thing as 'a turboprop engine'. There are some turboprop engines in which the pilot can control torque with the throttle and rpm with an rpm lever, Ron's proposal will work for those, but many types of turboprop have no rpm lever and offer no independent control of N1. In some neither turbine (N1), nor airscrew rpm, ever change in flight. In others both N1 and airscrew rpm are linked directly to the throttle position. The N1 limit of both types is often the same wet or dry. The different limits are often defined by (turbine) temperature rather than rpm or torque. With regard to water/meth there are then two significant cases.In the first case the designer of the engine sets up water/meth so that TOGA power can be obtained at high outside temperatures (the engine is TOGA rated to ISA + n) but it only has one TOGA rating, or the wet and dry ratings hardly differ. When uploading aircraft of this type the turboprop engine does indeed only require the appropriate entries in the handling notes. They will reference temperature limits for wet and dry TOGA rather than torque or N1. The second case is more usual. An engine designed so that water/meth allows (significantly) more power to be developed during TOGA under ISA conditions. To simulate a realistic take off in turboprop aircraft where the throttle controls airscrew rpm directly the end user must advance the joystick throttle to match the TOGA N1 limit, whether the take off is wet or dry. This is the key difference. Telling end users to apply the wrong airscrew rpm for one type of take off (either wet or dry) poses knock on problems that the proposed module will allow us to avoid. Generically the variable torque at constant N1 and constant throttle position arises from differential turbine temp trimming. As far as I know the modules and gauges currently available do not allow us to temp trim our turboprop engines. We cannot vary the torque available at constant rpm in turboprop engines where the throttle is controlling N1 and airscrew rpm, nor in engines where N1 is invariant.The first step to developing realistic temp trimming for turboprops is the potential FSUIPC module being discussed here. It is not a totally realistic solution, but it is a first step. Hopefully torque will vary at constant throttle position, constant N1, and constant airscrew rpm, as though the engine had been temp trimmed appropriately. Turboprop engines that use water/meth for both the above cases also exist and 'turboprop engines' are so variable in design that I expect there are some which obey other rules altogether. FSAviator

Share this post


Link to post
Share on other sites

"Generically the variable torque at constant N1 and constant throttle position arises from differential turbine temp trimming. As far as I know the modules and gauges currently available do not allow us to temp trim our turboprop engines. We cannot vary the torque available at constant rpm in turboprop engines where the throttle is controlling N1 and airscrew rpm, nor in engines where N1 is invariant." At set prop RPM, shaft torque varies with throttle setting in MSFS. While I've gotten torque to increase slightly as RPM is dropped at constant throttle."The first step to developing realistic temp trimming for turboprops is the potential FSUIPC module being discussed here. It is not a totally realistic solution, but it is a first step. Hopefully torque will vary at constant throttle position, constant N1, and constant airscrew rpm, as though the engine had been temp trimmed appropriately. " ITT appears to be reasonable in the MSFS turboprops. At higher TO temperatures one can reach the ITT limit before the torque limit. However, I have to wonder if ITT is that accurate overall. In that case, I'd have to make a gauge to calculate ITT. I did an XML gauge that calculates JT8D EPR and EGT closely (+/- 0.01 in the cruise range for EPR) to the values in a large JT8D table and I expect something similar could be done for any turbine powerplant. Assuming one has good data. One might emulate water injection by simply enabling a factor to make ITT display lower during injection. Then, one could push the throttles up higher. CN2 can be set to any limit in aircraft.cfg for 'TOGA' and SPD hold. A more sophisticated control would look at ambient pressure and temperature and limit the throttle setting so thrust, EPR, EGT, or Torque, ITT, etc were not exceeded. Ron

Share this post


Link to post
Share on other sites

Hi,can you use afterburner? Or are you using a prop engine? (Sorry it is not obvious from a quick scan of the thread). There is an afterburner thrust factor in .cfg I think or somewhere.Ian

Share this post


Link to post
Share on other sites

>Hi,>can you use afterburner? Or are you using a prop engine?>(Sorry it is not obvious from a quick scan of the thread).>There is an afterburner thrust factor in .cfg I think or>somewhere.>Ian It's a TurboProp. I don't know if 'reheat' has an effect, but that would only mess things up. Jet Thrust isn't all that high compared to prop thrust. Ian, as far as ITT goes, that's something you might be able to model (better). For either kind of turbine engine. Note ITT depends on compressor compression ratio. I don't know if it would be better to add the compression ratio heating as a function of CN to the "Ram" Compression and heating (TAT) or include both effects in one calculation. The idea is to get an idea of the form of ITT, one can then adjust it for the specific turbine. More efficient turbines have higher compression ratios, thus higher increase in T relative to SAT. One might be able to estimate the CR from the overall efficiency of the engine. There is no bypass in turboprop air flow, so I'd think adiabatic compression of a constant mass (per second) would make it easy to calculate temperature rise. Ron

Share this post


Link to post
Share on other sites

Hello Ron,> It's a TurboProp. I don't know if 'reheat' has an effect,>but that would only mess things up. Jet Thrust isn't all that>high compared to prop thrust. >> Ian, as far as ITT goes, that's something you might be able>to model (better). For either kind of turbine engine.What do you think MS are modelling here? Is ITT = Intermediate Turbine Temperature, Tt6 between the HP turbine and the LP turbine.If some one has a flight manual with this data we can do a regression with other data as I did for ERP and EGT on turbojets.> Note ITT depends on compressor compression ratio. I don't>know if it would be better to add the compression ratio>heating as a function of CN to the "Ram" Compression and>heating (TAT) or include both effects in one calculation.Well ITT would be ambient temp + ram heating + compressor heating including efficiency losses + burner heating - HP turbine extraction + efficiency losses. I think a manual would be better! > The idea is to get an idea of the form of ITT, one can then>adjust it for the specific turbine. More efficient turbines>have higher compression ratios, thus higher increase in T>relative to SAT. One might be able to estimate the CR from>the overall efficiency of the engine.The major variable is how does MSFS mangle the engine model and how do we match it to an engine in RL.> There is no bypass in turboprop air flow, so I'd think>adiabatic compression of a constant mass (per second) would>make it easy to calculate temperature rise. That is backwash from the props energising any incident surfaces as well an the intake. I don't think it is a very large temp increase. Thank you for reminding me of that.>RonIan

Share this post


Link to post
Share on other sites

Ron said;<Yes we agree how MSFS works out of the box. The problem is that MSFS does not have a 'turboprop flight model', it only has a 'Pratt & Whitney PT6A flight model'. I cannot describe it as atypical since there really is no such thing as a 'typical turboprop'. They are all prototypical. Unfortunately even in a product branded 'A Century of Flight' the PT6A remains the only turboprop model included for fixed wing use. Turboprop engines have been in commercial service for 54 of those 100 years.Many turboprop engines do not work like the PT6A at all. A number of FDE authors, myself included, have released flight (engine) dynamics that 'bend' the PT6A dynamics to address this problem, but none solve it. After investigating gauge based solutions, in conjunction with others, I believe that first generation turboprops like the Rolls Royce Dart, (throttle controls airscrew rpm directly), and second generation turboprops like the Allison 501, (airscrew and engine rpm are constant in flight regardless of any and all cockpit inputs), can only be simulated with any significant realism by processing data in a module outside MSFS and writing over the MSFS data using FSUIPC (or similar utility).These two engines alone power many of the turboprop aircraft that are of greatest interest to the MSFS community. It is easy enough to scale the SHP and ESHP of the PT6A to replicate their power output, but without external processing it is not possible to link realistic simulation inputs to realistic output.The Allison 501 can be replicated reasonably well without a modular solution, but prototypical operation requires temp trim to be added. This will require a module that, apart from other code, must be able to vary fuel flow and torque at constant throttle%, and constant rpm. It looks as though Doug may be able and willing to provide that part of the solution. The initial goal however is to allow both wet and dry torque and turbine temperature limits without variation of N1 and airscrew rpm in engines such as the RR Dart. Subject to testing, the proposed module should be a complete solution to this problem. I am aware that other FDE authors have already implemented incremental modular solutions to the 'RR Dart' problem, each moving the simulation a step further away from 'uprated PT6A, towards 'true RR Dart'. It is not my intention to criticise what has been achieved so far.<>It is reasonable for the PT6A, but that is not the problem. Even if it could not be manipulated within the FDE, gauges could modify where the needle is pointing at display time. The problem is disassociation of throttle %, N1%, N2% and airscrew rpm, from ITT inside MSFS for those types of turboprop that require this. I have no doubt that gauges can be made which calculate ITT, EPR, EGT, etc, for any engine given the data. The problem is not the calculation and display of the values, it is imposing them inside MSFS and preventing it from recalculating them for internal use. That requires a modular solution. The wider problem is simulation of the pilot action of 'temp trimming' and its consequences. Generically and in layman's terms, it is a means by which the fuel governor varies fuel flow and hence power to keep the turbine temperature at the pilot selected ITT (or other valid reference) whilst rpm% and throttle% are constant, or when the throttle is subsequently advanced to a defined throttle gate at a defined % of the quadrant. In the MSFS flight model for this purpose we have to manipulate SHP via manipulation of max torque, where max torque is internally associated with 100% (joystick) throttle. For the TOGA case I propose to ignore the rise in thrust associated with the wet flow as the *rise* in thrust due to water/meth creates very little power when TAS < Vr. Change of ESHP not due to change of SHP is too small to worry about. It could be added to the module code though. The ability to monitor flow and exhaustion of water/meth by reference to ADI arming switch status and throttle% could be done from within a gauge, but it may as well be done from within the module since it must test for both conditions anyway. Reduction of water/meth payload, and variable CG consequence, cannot be manipulated in real time outside a module.<>As I explained that would cause the aircrew rpm to vary in many turboprop aircraft. Having appropriate airscrew rpm is important during take off. Not all the turboprop FDE that may be downloaded clone the default code. Many already emulate characteristics of the real engine to varying degrees. Telling the end user to set the wrong airscrew rpm with the throttle (to obtain the differential wet/dry torque limit) for take off is one of the things the module being discussed here will avoid. Displaying a false ITT on the panel is easy. The problem is controlling what FS9 is doing internally with the thrust during a wet and dry take off at identical N1, N2 and airscrew rpm.The usual solution has been to allocate rpm levers to the distributed panels of a wide range of aircraft which do not have them in real life so that the end user may disassociate throttle position, turbine rpm and airscrew rpm by moving non existent controls. The module will (hopefully) overcome that need. This assumes that ©N2 exists and/or can vary in flight. In engines such as the Allison 501 as used in the C-130, P-3, CV-540, L-188, E-2, etc., turbine rotation is invariant in flight. The FDE author has to ensure that turbine rpm is invariant in MSFS. Manipulation of CN2 maxima cannot solve the problem in such engines.Writing two different sets of FDE, with different (wet and dry) power limits, in two different aircraft.cfgs is not otherwise a problem, but that is one of the 'clumsy' solutions the proposed module is intended to replace. Different air files can be aliased as ui_variations, but an aircraft.cfg cannot be aliased as an ui_variation. This is one of the drawbacks of moving FDE variables from the air file to the aircraft.cfg.With luck this thread will, (as a direct spin off from the original question about how to enable temporary higher limits for catapult launching), lead to the first of these goals being achieved. As it happens I don't think the solution will need to be very sophisticated, but I too thought otherwise before asking here in the hope of finding out.The first step is construction of the 'catapulting and arresting module'. This will not use power augmentation, but will not use applied forces either.The next step will be to address temporary variation of applied force along the reference datum line (as a generic case). This would allow any kind of temporary thrust augmentation including water/meth, JATO, RATO etc. The fluids would be decremented from the designated load_station.n with appropriate CG effects, improved rate of climb due to reducing mass etc., in real time. Applied as a negative value and defining the fluid as 'ammunition' the same module provides both recoil and ammunition mass depletion in real time from load_stations n to whatever.A force, is a force, is a force. However for the moment I propose to apply a singular net force along the waterline, positive or negative. To manipulate temporary applied force in real time, without affecting the 'main engines', it is necessary to use a modular solution.Ian, thank you for joining in. Could you please explain for the benefit of all how water/meth injection does, or does not, allow thrust to be augmented when used as combat emergency power in aircraft like the P-80 Shooting Star? Specifically, what happens if w/m is invoked at high level in cold air with low fuel flow at full throttle and the engine already below turbine temp limits? Is there any combat emergency power benefit? Assuming you are familiar with the RR Spey case, can you propose an algorithm that would convert the TOGA wet and dry thrust ratings at SL to a different flight level in ISA, for varying runway altitudes?The question is how maximum wet augmentation of thrust should vary with altitude. Does the effect diminish to zero and along what curve?Request relates to real world cases, not limitations of MSFS.I can probably work out the best way to impose it on MSFS if I can understand the real world case. It does not appear to be difficult to impose temporary variation of (jet) thrust on MSFS at constant throttle% if that is required. I simply do not understand whether that is relevant.At the moment I assume that in a turbojet or turbofan extra thrust when running wet always results from a higher turbine rpm and higher fuel flow. Does the fuel flow autoregulate during water/meth injection to create the extra thrust, or are the throttles moved? To this point we discussed mainly turboprops as the most difficult case appeared to be manipulating shp and eshp via torque and thrust (in MSFS) given the very different ways that different turboprops receive their input from the cockpit during the simulation.Finally, Doug may or may not wish to take on the more complex applied force variation module that I have proposed in this thread, but I am now in e-mail contact with him concerning the detailed requirements, and I have now explained both the goals and the proposed solution here as far as I can. Ian, thanks in advance if you are able to fill in the gaps. FSAviator

Share this post


Link to post
Share on other sites

>What do you think MS are modelling here? Is ITT = Intermediate Turbine Temperature, Tt6 between the HP turbine and the LP turbine.http://www.pwc.ca/en/0_0/0_0_14/0_0_14_2.aspit may help to better understand my description. When you look at the PWC illustration, note the dotted vertical line that separates the power section on the left from the gas generator section on the right. This is the 'C' flange I referred to earlier; it's the mating flange where the power section and the gas generator section are bolted together. This is the approximate location of the ITT busbar. >If some one has a flight manual with this data we can do a regression with other data as I did for ERP and EGT on turbojets.

Share this post


Link to post
Share on other sites

Hi all,I'm glad this thread has got so much feedback, which (due to my lack of knowledge) has gone a bit over my head unforfortunately :-)I'm also in contact with Doug Dawson, and it appears (if I understood his explanation correctly) he has found a way to directly set the aircraft's groundspeed via FSUIPC, which he has proven with a "catapult" testgauge he made.Which (going back to my original question) is probably the most realistic way to model takeoff/landing on a aircraft carrier: an external force applied to the aircraft (the shuttle of the catapult pushing the aircraft forward resp. the cable pulling on the aircraft after a catch), thereby emulating the aircraft's accelleration / decelleration without modifying the aircrafts characteristics itself....Will be continued ....Regards, Rob

Share this post


Link to post
Share on other sites

>Hello Ron,>>>> Ian, as far as ITT goes, that's something you might be able>>to model (better). For either kind of turbine engine.>>What do you think MS are modelling here? Is ITT = Intermediate>Turbine Temperature, Tt6 between the HP turbine and the LP>turbine. EGT is not realistic for turbojets (though it can be set to be about right under cruise conditions) and ITT appears to be based on the same formula. Settings in the AIR file adjust ITT and EGT the same way. One common difference is the 'Rate of Change'. Thus, I doubt ITT is very accurate either. All I can say is they are better than the 'EPR' variable. ;)>If some one has a flight manual with this data we can do a>regression with other data as I did for ERP and EGT on>turbojets. I don't have much info on turboprops. It seems this is something that can be at least approximated as explained. Once one has a simple theoretical model for ITT he can enhance it, if necessary, for a specific powerplant. Note EGT and ITT are also used for reciprocating engines. I don't know why EGT is so closly related to ITT but a data from a real instrumented AC also showed the correspondence. Perhaps ITT is already based on aidiabatic compression. One scales the reading in the AIR file, perhaps that would tend to account for an intercooler.>That is backwash from the props energising any incident>surfaces as well an the intake. I don't think it is a very>large temp increase. Thank you for reminding me of that.>Ian I suspect the 'cooling factor' for Oil and CHT is related to a cowling parameter explained in McCormick. '0.65' may apply to the intake/outlet area ratio for the air cooling. Note 0.0 gives no IAS effect on cooling. IOW, no intake for air cooling. Ron

Share this post


Link to post
Share on other sites

I don't have time to comment on everything here. I haven't done all that much with turboprops. As far as RPM vs 'throttle' goes, one can set 'Prop RPM' with a gauge which could set any desired variation relative to the 'power lever' or whatever else might change RPM. For example, one might set Prop RPM to "1800 + (Throttle * 200)". As one advanced the throttle the prop RPM would increase to a limit of 2000 RPM. Pull the throttle back and RPM drops some. Prop thrust would vary much more. Actually, RPM would drop below 1800 at low throttle, just as it does with no gauge setting. It's the RPM Command that varies as I showed. Or, command the RPM to vary some with shaft torque. If the FS model doesn't handle a realistic sag in RPM at high blade angles and partial throttle one could control it indirectly. I'd think the end result would be appropriate shaft torque, prop thrust, fuel flow, etc. In FS, the throttle actually controls engine torque. A CS prop changes blade angle as necessary to hold RPM constant as shaft torque changes. While a FP prop lets the engine speed up to the RPM where Prop Torque is in equalibrium with powerplant torque. In the FS Turboprop model, N2 = Prop RPM * Gear Ratio. One can think of N2 as N High and N1 as N low. Both turbine and compressor have high speed and low speed rotors, though FS links the gear box only to N2. In turbine jet engines CN1 is mapped from CN2 as a function of Mach number. One can set CN1 = CN2 in TBL 1502 though EGT will not be correct then. Jet Thrust is a function of CN1, TAS, and TBL 1506 entries. I assume N2 torque is a function of throttle setting and the 'Friction Torque' table. Jet Thrust isn't that significant in turboprop engines and it would seem the complicated 1506 and 1507 tables are much more than is needed. While the Throttle tables (which involve Mach and IAP) control N2, the Friction Table should allow one to model a change in shaft torque vs RPM. Conversely, if one changes Prop RPM N2 has to change, and that reflects backwards to N high torque at a given throttle setting. Some time ago I tried to find the RPM vs Torque variation by setting essentailly zero blade angle. Howver, the prop code didn't work correctly at that time and I couldn't see how fast the turbine (N2) would go when loaded only by the Friction Torque. Knowing 'no load' RPM would show how the Friction Torque table is calibrated. Though, I now think it is in ft-lbs vs 'per cent' N2 RPM. Where the friction torque is relative to the turbine, not the prop shaft. Since my test I think the turboprop model has more settings. Such as for 'min on ground beta'. It might be possible to get useful results at this time. Further, there is the newer TBL 1548, which sets torque vs ambient air density. One could reduce the 1.00 torque factor at SL (0.00277 sl-ft^2) to 0.1 and might then be able to get a low enough RPM with zero prop torque to see if the Friction Torque table works as I think it should. There is also TBL 1508 "Turboprop Torque vs CN2?". It can't relate how shaft torque varies as one loads down the turbine, rather it appears to set the available torque as a function of CN2. Higher CN2 = Higher torque. I don't know if more than three data pairs can be set in that table, regardless, the middle pair and the high end pair give some freedom in setting shaft torqe and RPM variations. Ron

Share this post


Link to post
Share on other sites

>Ron said;>><in MSFS.>>>Yes we agree how MSFS works out of the box.I thought that for the turbojet but FS9 seems to have simplified how some of the tables are read. Yes the TP is the worst case nightmare scenario and some people have been hinting I should work on it but so far I have stuck to the turbojet/fan as this is ONLY rocket science.> The problem is>that MSFS does not have a 'turboprop flight model', it only>has a 'Pratt & Whitney PT6A flight model'. I cannot describe>it as atypical since there really is no such thing as a>'typical turboprop'. They are all prototypical. Unfortunately>even in a product branded 'A Century of Flight' the PT6A>remains the only turboprop model included for fixed wing use.>Turboprop engines have been in commercial service for 54 of>those 100 years.It was only fashionable for a few years in the 1950s and there are not many technical books on the subject, despite the pile of piston, prop and jet books I have. Can anyone recommend the best one?>Many turboprop engines do not work like the PT6A at all. A>number of FDE authors, myself included, have released flight>(engine) dynamics that 'bend' the PT6A dynamics to address>this problem, but none solve it. After investigating gauge>based solutions, in conjunction with others, I believe that>first generation turboprops like the Rolls Royce Dart,>(throttle controls airscrew rpm directly), and second>generation turboprops like the Allison 501, (airscrew and>engine rpm are constant in flight regardless of any and all>cockpit inputs), can only be simulated with any significant>realism by processing data in a module outside MSFS and>writing over the MSFS data using FSUIPC (or similar utility).>>These two engines alone power many of the turboprop aircraft>that are of greatest interest to the MSFS community. It is>easy enough to scale the SHP and ESHP of the PT6A to replicate>their power output, but without external processing it is not>possible to link realistic simulation inputs to realistic>output.>>>I am aware that other FDE authors have already implemented>incremental modular solutions to the 'RR Dart' problem, each>moving the simulation a step further away from 'uprated PT6A,>towards 'true RR Dart'. It is not my intention to criticise>what has been achieved so far.>>>I did the original regression fit for the EPR and EGT for this engine (end of ad break).>Reduction of water/meth payload, and variable CG consequence,>cannot be manipulated in real time outside a module.><factor to make ITT display lower during injection. Then, one>could push the throttles up higher.>>>Ian, thank you for joining in. Could you please explain for>the benefit of all how water/meth injection does, or does not,>allow thrust to be augmented when used as combat emergency>power in aircraft like the P-80 Shooting Star? Why do you mention the P-80 specifically? I have a part of a manual for the T-33 Silver Star and did an engine model for a pilot owner last year. Can't remember if it did wet operation.Whittle knew about wet thrust augmentation in the 1930s. When he built the W.1 his assistant sprayed a methanol and water mixture into the intake. UNFORTUNATELY he was unable to get his attention fast enough to stop him before the engine overspeeded and blew up. I think he started to build the W.2 after that.>Specifically, what happens if w/m is invoked at high level in>cold air with low fuel flow at full throttle and the engine>already below turbine temp limits? Is there any combat>emergency power benefit? Wet augmentation works by 2 ways. 1. The methanol is a fuel so the enthalpy of combustion will add energy to the thermodynamic cycle.2. Thermodynamic efficiency is proportional to the ratio of the max temp (TET) to the min temp ambient. It you can use the enthalpy of evaporation to cool the air flow at the intake this efficiency can be increased.PS the Merlin design improvements of Hooker used the evaporation of fuel to improve the efficiency of the carburettor which was not available in the fuel injected BMW engine of the Bf.109.>Assuming you are familiar with the RR Spey case,No I don't actually have a Spey engine manual only an RB.211 and an Olympus manual. Can some one send me a copy please.> can you>propose an algorithm that would convert the TOGA wet and dry>thrust ratings at SL to a different flight level in ISA, for>varying runway altitudes?Possibly.>The question is how maximum wet augmentation of thrust should>vary with altitude. Does the effect diminish to zero and along>what curve?>>Request relates to real world cases, not limitations of MSFS.>>I can probably work out the best way to impose it on MSFS if I>can understand the real world case. It does not appear to be>difficult to impose temporary variation of (jet) thrust on>MSFS at constant throttle% if that is required. I simply do>not understand whether that is relevant.>>At the moment I assume that in a turbojet or turbofan extra>thrust when running wet always results from a higher turbine>rpm and higher fuel flow. Does the fuel flow autoregulate>during water/meth injection to create the extra thrust, or are>the throttles moved? Not necessarily.>To this point we discussed mainly turboprops as the most>difficult case appeared to be manipulating shp and eshp via>torque and thrust (in MSFS) given the very different ways that>different turboprops receive their input from the cockpit>during the simulation.The catapult would be a lot easier. :-)>Ian, thanks in advance if you are able to fill in the gaps.I would be happy to do so. Perhaps there is some useful manuals books etc people have access to. >FSAviatorIanPS ERP is my typo for EPR and thank you for the definition of ITT.

Share this post


Link to post
Share on other sites

Earlier I said,80 Shooting Star?>>80 specifically? I have a part of a manual for the T-33 Silver Star..>>I consider the T-33 to be an aircraft like the P-80 so I would be pleased to receive an explanation based on the T-33. What I am really trying to grasp is the error involved in representing thrust augmentation due to water/meth injection into the turbine stage, as injection of fuel into the afterburner. This latter method has been universally adopted by FDE authors to date. There appears to be little error for the TOGA case, but I find the high level, high Mach, case less clear. I understood your reply but could not use the information to estimate the % error I mention above. Taking your reply as a whole I conclude that the complication of calculating a more realistic value for combat thrust augmentation using means other than default afterburner may be more effort than it is worth. Even the CFS community seem to have little interest in this aspect of realism so I leave it up to you whether you think this aspect of realism is worth pursuing further.I said,>To this point we discussed mainly turboprops as the most>difficult case appeared to be manipulating shp and eshp via>torque and thrust (in MSFS) given the very different ways that>different turboprops receive their input from the cockpit>during the simulation.Ian replied,<>Turboprop augmentation is probably even easier to implement. MSFS has the default ability to re-calibrate the joystick throttle for turbojets and turbofans by temporary substitution of a different MAX_TRUST.n value to simulate afterburner. The proposed turboprop module potentially does no more, but instead varies MAX_TORQUE.n to simulate wet v dry available torque at any n% throttle. MSFS will recalculate the resulting temperatures etc, without our help. The accuracy of such calculation is a separate subject. I do not expect the prospective module to address that. However it would be nice if the module also contained the code to read the available fluid mass and deplete it to zero in real time. I now realise that this is also simple for anyone who is familiar with the construction of modules linked to MSFS via FSUIPC. Rob said,<>Having now beta tested the (latest) module (written by Doug) I am happy to report that it overwrites airspeed and that the lift and drag equations use the overwritten value appropriately with logical dynamic consequences as the aircraft unsticks. Accordingly it works both as a CV catapult utility and as a convenient means for overcoming 'Microsoft sticky water', for both the taxi and take off cases. It therefore allows hydroplanes to operate from water up to their real maximum take off weights whilst using only realistic TOGA power. The FDE author will be able to recommend the augmentation value that replicates realistic acceleration in all cases. The catapult module does not achieve this by realistic means, but that is potentially an advantage as the numeric augmentation value required is a constant and neither wind vector dependent, nor engine type dependent. I have proposed some potential improvements and developments via e-mail, but it works as it is.I would like to thank Doug for providing a solution to the CV and hydroplane simulation problems inherent in MSFS. I hope he will now take up the challenge of providing realistic temporary variation of max torque at 100% throttle for the wet TOGA case in turboprop flight models.FSAviator

Share this post


Link to post
Share on other sites

RF>IK>I did the original regression fit for the EPR and EGT for this engine (end of ad break). Hate to bring it up here, Ian. But remember I tried your EPR/EGT formulas and they didn't work! I ended up starting from a SS someone else made, noting the formula for EPR he found didn't need the TAT correction if I changed N1 to CN1. I couldn't see why EGT varied from 1X to 3X SAT, depending on EPR. But, working in an intuitive fit anyway. For reference, a start is to make EPR = a + b*CN1. A straight line fit is much better than the MS EPR. My fit involved a straight line up to some value of CN1, then a third degree polynomial to handle it up to about 2.15. However, a straight line, then a second degree polynomial would still be pretty good, and not deviate so much above EPR = 2.15 Finally, as a minimum, make EGT = c + d*EPR + e*(TAT-15). Where I think 'e' is '1' for higher values of EGT. For the JT8, EGT is about 500 C at TO CN1, SL, 15 C. That would be similar for many turbines. I modified the JT8D EPR for a JT3D. TO CN1 was higher for the JT3D so I multipiled CN1 by about 0.85 before hitting the original EPR code. To get EPR = 1.82 at CN1 ~ 107%. I then had to multiply EPR by something like 1.1 before hitting the EPR to EGT code so EGT would be come out about the same as before. I don't know how close the EPR and EGT values are for a JT3, but they look reasonable. At least I get the right values at TO. All in all, I think my original JT3D EPREGT code can be adjusted for many turbines by only adding and adjusting the two factors I added to approximate the JT3D. THRUST vs CN1 HAS TO BE CORRECT FOR EPR EGT TO COME OUT RIGHT! It would be nice if we knew how to calculate EPR from relative FS Thrust. Then, CN1 wouldn't have to be accurate as far as having an accurate EPR (and EGT). All I know is Thrust is proportional to EPR at a constant altitude and Mach number. It looks like EPR = 1.0 means zero thrust, while EPR = some higher value, such as 2.0, means maximum continuous thrust. The approximately straight line variation of EPR with CN1 or CN2 is consistent with the graphs McCormick's text displays. I did not get in the small variation in EPR due to Mach number. It is only signficant below EPR = 1.6 for the JT8D. That is important for approach EPR but not for climb and cruise. I put my EPREGT code in a separate XML file. The small file also displays the EPR and EGT digitally. The values could be used in graphical gauges easily enough. It's only a few lines of XML but hard to understand how the RPN works. I added p-code in comments so it can be converted to C as desired. I'd post it here but can't UL files; Java is busted in my IExplore. Ron

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this