Sign in to follow this  
adr179

Manifold Pressure

Recommended Posts

Hi all, using the variable manifold pressure in XML. As the engine revs increase, so does this variable. My experience of this pressure is that is reduces with revs, that is, a lower pressure exists because more air is being pulled through the manifold. Should this variable be subtracted from a possible maximum? I also thought of subtracting this from atmospheric pressure, as it must vary according to changes in atmos pressure, but the values can then become negative. Can someone point me to a solution for showing a realistic manifild pressure. This is obviously for a piston engine. I have searched the archives here but not fould a solution.cheers,nick

Share this post


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

Nick,I know nothing about manifold pressure. However, I do know a bit of XML :-) So, if you could bring a practical example of what values do you need to relate and how, maybe I could think of something.Tom

Share this post


Link to post
Share on other sites

Greetings Nick,The answer has two parts. How this stuff works in FS9 and how it works in real life. You probably understand the first part, but I will explain for the benefit of any readers who do not, since it is often misunderstood. Whether in FS9 or in real life such gauges only display a value. They do not calculate it, or its relationship to any other value. If the FS9 gauges are displaying the current values in memory the gauges are working perfectly, whether or not the values are realistic. In FS9, just like every MDL, output gauges just sit there and wait for a flight dynamics author to tell them what to do. Their code holds no relationships and no consequential behaviour. If this were not the case default gauges could not exist. They do exist and they can display thousands of different relationships for thousands of different engine types and marks. All the gauge author has to do is retrieve the current value calculated within FS9, to the order of the flight dynamics author, and then make the needle point at that value. A non default MAP or RPM gauge does not require code that is absent from a default gauge. There is nothing missing from default MAP and rpm gauges. No new code needs to be developed. A different bitmap may be desirable and since e.g. 25 inches may be at a different position on that bitmap new code is needed to point the needle at 25 inches where it is on that new bitmap, if 25 inches is what the flight dynamics author encoded for the circumstance.The relationships, the equations that drive them, and the aircraft behaviour that ensues, are encoded elsewhere. Partly in the hard coded flight model (FM) provided by Microsoft, and partly within the individual third party engine and aircraft specific flight dynamics (FDE), provided by the flight dynamics author. Moving to real life.If the engine lacks a constant speed airscrew, and also lacks a supercompressor, with everything else held constant, the manifold pressure will always tend to rise whenever engine rpm rise because the throttle cable opens the butterfly valve in the choke tube to promote that result. When a more complex piston engine has an rpm lever as well as a throttle, even if the engine also has a supercompressor, there is no reason why MAP should never rise when rpm are increased and equally no reason why MAP should never fall when rpm are increased. It just depends.Those real life dependencies are precisely what flight dynamics authors encode, on an engine type, variant, and mark basis, air file by air file.

Share this post


Link to post
Share on other sites

Hi NickThis Prob total wrong but hey I like getting shot down in flames its how I learn no pain no gain:) My understanding of Manifold pressure is as the revs raise so will the manifold pressure,more air is forced into the engine means more pressure.As alt climbs air thins meaning less pressure,then the supercharger is engaged(make it SO number one :D ) to stuff more of the thin air into the engine cheersWozza

Share this post


Link to post
Share on other sites

Many thanks guys, so using RECIP ENG1 MANIFOLD PRESSURE without any modifying factors should give a realistic value. Maybe of interest, this particular gauge has the range 10 to 35 inHg for the needle. The numeric value has a minimum of about 5 inHg. cheers,nick

Share this post


Link to post
Share on other sites

Nick The MAP gauge with engine off normally gives the ambient pressure, Cross check with the altimeter at airfield altitude. 35in is good for normally aspirated but say a Turbo Senneca will give around 39 to 41 on takeoff ground roll at near sea level with the boost lights flashing and climbout close to high 30.

Share this post


Link to post
Share on other sites

I was also looking for a kind of a workaround for the manifold pressure gauge behaviour, since it definitely is NOT REALISTIC, not even in the default FS9 DC3. After some 4000 hours of flying "the real thing"I feel competent to say that. The main point is that this statement by Aviator: "A non default MAP or RPM gauge does not require code that is absent from a default gauge. There is nothing missing from default MAP and rpm gauges. No new code needs to be developed." is misleading, since I have a feeling it's almost impossible to tweak the variables that are sent to the gauges, we do need a different code for the MP gauge to make it at least fake correct behaviour that is:In a variable pitch propeller and a non-turbocharged engine combination the manifold pressure is decreasing(without touching the throttle levers, that is)at an average rate of 1in.Hg per 2000feet in altitude change and this is modelled in the simulation. The situation that is absolutely not modelled in the simulation is that at a constant altitude when the propeller levers are moved, thus changing theRPM there is a noticeable change in the MP, lower RPM, higher MP and vice versa.In a turbocharged engine MP is kept the same with the altitude changes by means of a special vastegate up to a certain altitude, reffered to as "critical", even there is nothing critical in the situation, and then at higher altitudes MP falls of at a standard rate, and this behaviour is NOT MODELED in the simulation at all, and the same situation is with the RPM changes, where the MP raise and drop is also not modeled. So what we need are actually two MP gauges, one for the normaly aspirated, variable pitch propeller/engine combination and another for a turbocharged/variable pitch propeller combo.I'm ready to provide help in form of information of realistic behavior and values to the XML guru's who might want to give it a try, since the gauge will become well to complicated (editing two additional values internaly from three variables provided by the sim) for my modest knowledge of XML.Those interested, please send a PM, since I really don't want to readposts cluttered with statements of how everything is actually perfectly done already. If that was the case, many topics like this one wouldn't have been written.

Share this post


Link to post
Share on other sites

>In brief: the airfile author can change the flight>dynamics code (airfile, aircraft.cfg file) to allow the engine>gauge variables to present the correct information. Then, if>necessary, and in the gauge code, you can change that code as>required to tailor the final indication displayed by the>instrument to suit your needs.That is the precise sequence I follow:1) code the gauges to report the requisite sim variables, calibrating to any non-linear scales...2) send project to FDE person...3) make any needed scalar tweaks to the gauge's variables as needed to reflect reality as closely as possible.The major point being made though is simple. The flight dynamics must be properly set prior to making "gauge tweaks..." ;)

Share this post


Link to post
Share on other sites

""The situation that is absolutely not modelled in the simulation is that at a constant altitude when the propeller levers are moved, thus changing theRPM there is a noticeable change in the MP, lower RPM, higher MP and vice versa.In a turbocharged engine MP is kept the same with the altitude changes by means of a special vastegate up to a certain altitude, reffered to as "critical", even there is nothing critical in the situation, and then at higher altitudes MP falls of at a standard rate, and this behaviour is NOT MODELED in the simulation at all, and the same situation is with the RPM changes, where the MP raise and drop is also not modeled. ""***********************************I believe that FS unmodelled behavior you stated can be perfectly simulated using XLM code. However, you'll need to know which are the real numbers for the relationship between RPM increase/decrease and MP decreas/increase. Basically two things to consider before coding startup:-If there should be a significant difference in engine performance as MP raise/drop in response to RPM changes, you would have to tune RPM and throttle events by code, faking its respective lever bitmaps'positions (ie "throttle lever position", etc)- On the opposite, if there is not such a difference noticeable in some kind of flight characteristics alteration, should be enough to fake the gauge's readings using polinomials extracted from real tables.Tom

Share this post


Link to post
Share on other sites

Thank's for Your reply Tom.In real life there is a "significant difference in engine performance", even dramatical, it quits after a serious abuse by means of setting tolow an RPM against to high an MP setting. However, by applying just normal, recommended factory settings for combinations of RPM/MP that produce certain recommended power settings for 55, 65 and 75% power reffered to as long range, economy and fast cruise by some manuals, there is no obious penalty anywhere, not in engine performance or in fuel flow, since it actually ends up equal once all the settings to the RPM an MP are done.The main purpose of all this is to produce a realistically behaving gauge and by doing this also increase the cockpit workload to a realistic level. Or is it? Since I flew the kind of hardware for over 4000 hours I'm maybe even more disturbed by lack of a correct reaction from the gauges, since I'm used to do the correct actions when changing power, so the "easy way" is actually a harder way for someone that knows what handling of this kind of engines is all about. What needs to be done is to add a dependency to the output manifold pressure values that are displayed by the gauge in a way that the MP will rise if the RPM is decreased (RPM lever position)and at the same time to compare the RPM handle position against the throttle lever position and increase or decrease the MP pressure only if the position of RPM handle against throttle(MP) handle is relatively changing. A realistic value of change to start with is some 10% of change in MP with 10% of change in RPM, so if the RPM is decreased from 2500 to 2250(10%) the manifold will raise from 23 to 25.5 and this increase and decrease of MP can be considered linear thru the normal operating ranges. It's not that I'm lazy or something, but this kind of programming in XML is simply well above my current capabilites.At the end I need to appologise for a mess in my first post, I overlooked that the aircraft I was testing has some entries in the engine section missing, thus producing strange, but actually correct behavior of the MP gauge, that is otherwise correctly programed- reffering to critical altitude, fixed vastegate part.

Share this post


Link to post
Share on other sites

""What needs to be done is to add a dependency to the output manifold pressure values that are displayed by the gauge in a way that the MP will rise if the RPM is decreased (RPM lever position)and at the same time to compare the RPM handle position against the throttle lever position and increase or decrease the MP pressure only if the position of RPM handle against throttle(MP) handle is relatively changing. A realistic value of change to start with is some 10% of change in MP with 10% of change in RPM, so if the RPM is decreased from 2500 to 2250(10%) the manifold will raise from 23 to 25.5 and this increase and decrease of MP can be considered linear thru the normal operating ranges. It's not that I'm lazy or something, but this kind of programming in XML is simply well above my current capabilites.""*************All this seems feasible to code in XML...Ball goes to Nick's field now! :-)Tom

Share this post


Link to post
Share on other sites

Thanks Tom, I've caught the ball but don't know what game I'm playing :)From what I have read above, this is not a simple parameter to model.I think the only way to model this is to obtain performance characteristic graphs from the actual engine itself. Not easily obtainable on the net. The engine, FYI, is a Teledyne-Continental Model IO-550-B. Or, unless I have missed some points, can someone state, maybe in tabular format, pressure characteristics.cheers,nick

Share this post


Link to post
Share on other sites

Hi Nick!Actually You don't need any kind of performance data for both the gauge to act realisticaly and the flight model to perform exactly the way it performed before the mods, provided that You stay within the parameters I described in my previous post. A slight discrepancy will only be happening only when the RPM handle is moving against the throttle handle being at a fixed position. Once the power settings are done, one will again end up with the same relationship of MP&RPM and the gauge influence to engine power output will be exactly the same as before, so I don't see why You need any kind of performance graphs just to tweak the gauge behavior internally.The value of 10% that I stated in my previous post maybe looks like a rough guess, since it's a round figure, but it's correct and will actually produce a realisticaly behaving gauge.

Share this post


Link to post
Share on other sites

I will respond to specific matters arising and then provide some insight into the real problem that lies at the heart of all the follow up posts about

Share this post


Link to post
Share on other sites

""Your job is making sure that the big needle with the knob on top is displayed at exactly 50% in the console arc when the gauge is sending the message 'big needle with knob on top = 50% travel', and nothing more.""It depends. If you are working on a project that has to be as real as it gets, you need to suit FS parameters and simulate gauge readings so that 'big needle with knob on top = 50% travel' comes from the REAL aircraft requeriments and not otherwise. That's the big challenge every panel developer has to deal with. In fact, most of the very popular payware panels (LDS, PMDG, etc) has some "cosmetics" on their gauges, as to simulate as much as possible the real systems functions.FS .air file is a pretty well job done by the MS team. However, in some sections, like Engine tables for example, things are a bit rigid. Interpolation between columns follows a linear pattern, where in RW values usually follow a polinomial order, so no matter the best work you do with those tables, there would be inaccurancies that can be solved by coding the panel gauges properly.EPR and EGT in turbo/jet engine are unrealistically modeled to say the least. But they can be simulated to match RW data almost perfectly, and with no penalty at all in aircraft performance.I agree flight dynamics should be respected, but not to the point of compromising REAL data output in panel gauges for those of us who want to play "real", in those situations where FS performance won't be substantially altered by customized code.As a specific example, it tooks me quite a lot of time to program the REAL engine startup sequence for my 757, yet being not finished at all. The complexity of this process goes well beyond what the generic FS jet engine is able to simulate, and there is no smart FD adaption that can make the numbers match as needed. But a bunch of XML polinomials did make my day, and now the needles point where Boeing (and not MS) intended they have to.""<>Of course it is. Those data are then carefully imposed on the engine specific flight dynamics by the flight dynamics author.""Unfortunately, flight dynamics alone can't solve much of complex aircraft system's behavior, due to the inherent limitations stated above. That's when smart coded gauges do their job...""Consequently there is no problem to be solved.""For all of us who make panels for our own enjoyment (or other valid reasons), thanks god ALWAYS will exist problems to be solved!:-) Tom

Share this post


Link to post
Share on other sites

FSAviator,Man, as much as I hate to admit it, it looks like Bill Leaming was right when he stated in another thread that if someone asked you for the time, you would build them a watch. More like an atomic clock

Share this post


Link to post
Share on other sites

"Man, as much as I hate to admit it, it looks like Bill Leaming was right when he stated in another thread that if someone asked you for the time, you would build them a watch. More like an atomic clock

Share this post


Link to post
Share on other sites

>>>>Even though I'm a member of the "professional develolper class," I'm humble enough to admit that I'm on one of the lowest tiers - if not the bottom itself.<<<

Share this post


Link to post
Share on other sites

Answering Nick's questions in full took hardly any time at all, but useful information in the forums is increasingly shouted down by consumers who have failed to control what happens within FS9, but who feel the need to blame developers for their failure. That plague has now spread to developer forums. My explanation of the bi-polar nature of the market was mostly directed at Nick. He has to decide who his target consumer is. The 2% or the 98%. If the former he must obtain the manuals and impose the data upon his product. If the latter he should neither bother, nor apologize. Ford have no reason to apologize for developing and selling the Focus just because a Ferrari is what a select few demand. Those who desire a Ferrari should not go to Ford dealerships and rant because the Ford dealer is unable to supply a Ferrari and those who supply Fords have to stop pretending that they are just as good as Ferraris.This thread is all about the realistic coding of MAP v rpm correlation in piston engines. I have explained that we have known for many years how to solve all the relevant problems of realistic usage and development, but also that since 98% of consumers do not desire realism there is limited reason to develop realistic code. Douglas, I devoted significant time to your point about supercharger operating complexity because I thought you would appreciate a candid explanation of why a capability which you have requested more than once is still not available. Since both turbochargers and superchargers have waste gates and the means to simulate those is available from third parties your specific wish can only be that the consumer be required to control the rpm of a supercharger manually and independently from engine rpm which they are already required to control manually and independently from fuel flow. I believe you have failed to understand that there is no way to make this optional. It can only be present or absent.I wonder if you believe that because developers do not impose this extra burden on consumers that we do not automate the blower switching? The consequences of blower switching is often incorporated in products aimed at the 2%. What most of them would not welcome is mandatory manual compliance. It follows that if a consumer using such a product wishes to perform manual blower gear selection all they need to do is add the requisite number of dummy supercharger gear selectors to the relevant cockpit environment and add the manual switching to the handling notes. Experienced non aircrew consumers are struggling with the mandatory realism already present in some products. Even those who develop for the 2% and who have succeeded in incorporating substantial realism into their simulation experience have to think carefully about the net advantage of making a realistic automated process manual and mandatory.Experienced developers have a good feel for how well consumers are coping with current products and are pushing the mandatory realism boundary as fast as they dare, but before they can add more mandatory realism they need more consumers to develop the intention to incorporate realism within their simulation experience. That is why those who are pushing the realism boundary forward need to negate the nonsense from the naysayers, and explain that nothing is impossible provided sufficient consumer demand exists.Consumer acceptance of increased mandatory realism is not a payware versus freeware issue at all. This is about pushing boundaries of consumer acceptance. It is not about money. The market gets what it demands from both payware and freeware developers.<

Share this post


Link to post
Share on other sites

WOW, this topic really developed! Are we finally, after two pages of bla-bla, after offending 98% of FS community by declaring them "not interested" and some other dueling, maybe ready for some positive creativity?Since, Douglas, the plane doesn't need to be a vintage category, even new production planes with wariable pitch propeller (PA32 Saratoga or PA46Malibu or the twin Senecas) still uses the same technology and consequently their MP raises if the RPM is reduced, there is no "set it, forget it" option like in the turoprops when managing the power settings. I don't care what Microsoft will or won't do, their main goal is to sell the product by making it more and more "sexy", but I'm sure there is quite a hefty number of users that do know the stuff. Personally I don't mind if there is a flock of seagulls in my home bay or not, but I do get excited if the aircraft, it's systems and instrumentation are far from what they're supposed to be. Have a look at the FS9 default DC3:RPM and MP gauges are racing from their minimums to maximums at a rate that would make any formula one driver say:"Hey, I need this kind of engine in my car!", but they were supposed to imitate the reactions of a 1830 cubical inches in 14 cylinders of the R-1830 Twin Wasp. The RB needle of the ADF is able to turn from the off to the position of the current value in a fraction of a second, the ADF gain is "jumpy" and indicating signal only to some 10 miles from the station. And there is more, but there are still some people here on the forums, that will claim, that everything was already perfectly done, and nothing needs to be changed and these claims are as furious as screams of a drowning person. I did managed to cure most of the mentioned issues by, let's say tweaking, of the existing gauges with no penalties whatsoever and got stuck with the manifold pressure, since I don't know enough of XML coding. I do know which relationships need to be adjusted, but can't produce a working code for the situation. My activities in this topic were never intended as a criticisms of a product called MSFS 9 - it is treaded as a game, all of us who are trying to increase the level of it's realism can only be thankfull to the Microsoft for providing us with the open code and SDK's, making all this a great hobby for all of us and a job and source of income for the best. Is anybody trying to solve the MP gauge behavior issue?

Share this post


Link to post
Share on other sites

>Have a look at the FS9 default DC3:>RPM and MP gauges are racing from their minimums to maximums>at a rate that would make any formula one driver say:"Hey, I>need this kind of engine in my car!", but they were supposed>to imitate the reactions of a 1830 cubical inches in 14>cylinders of the R-1830 Twin Wasp. The RB needle of the ADF is>able to turn from the off to the position of the current value>in a fraction of a second, the ADF gain is "jumpy" and>indicating signal only to some 10 miles from the station.You are describing two different issues: gauge dampening and gauge input errors.The example of the ADF needle is a case of insufficient "gauge dampening," meaning that the rotation of the needle requires additional lag, or latency to at least provide the appearance of reality. In the real world the bearing from two tuned NDBs does in fact change instantaneously, but the indicating needle has a dampening mechanism added to mitigate quiver and rapid movements.The example of the MP gauge on the other hand, is a case of gauge input errors. This does not make the gauge faulty: it is reporting accurately whatever input is provided to it. Granted, as in the case of the ADF needle, some additional dampening may be applied, but this will not change the input error(s).As FSAVIATOR points out, all the calculations are done within the core code of FS, based on coded tables within the .air file and/or data sets enumerated in the aircraft.cfg file...If you wish to have the MP gauge on the DC3 behave with fidelity, there is no place other than the FDE to make such adjustments.It is certainly possible to code some algorithim within either a C or XML gauge that will fake such behavior, but that won't alter the fundamental performance behavior of the sim's engine model, nor its operational behavior.

Share this post


Link to post
Share on other sites

Thanks for Your reply Bill. I'm aware of and do understand all of Your statements. And I never claimed, the MP gauge in any of the default aircraft was faulty, my only claim was always about unrealistic behavior, otherwise I know that the gauge is showing exactlly correct values supplied from the air file and Aircraft.cfg.As I already said, I managed to produce quite resonable behavior of all other gauges but MP. I was fiddling with the 500 range values in the air file to achieve at least some feel of big mass inertia in the engine propeller combination, but the problem with the MP gauge persists and I really don't see other solution but (from the purist's point of view) to fake the gauge behavior, since I strongly bielive, that the final user won't bother how it was done if it "plays" as it should. I really don't expect any other parameter will need an alteration after implementation of a gauge modified in a way I already described before. But even if I'm wrong about this I don't see a problem why the necessary parameters in the air file and Aircraft.cfg couldn't be changed afterwards if necessary.

Share this post


Link to post
Share on other sites

>>>>Answering Nick's questions in full took hardly any time at all, but useful information in the forums is increasingly shouted down by consumers who have failed to control what happens within FS9, but who feel the need to blame developers for their failure. That plague has now spread to developer forums. <<<

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