I've been following the thread intently over the last few days, and after some initial testing today I may have a solution. If you want it NOW, skip the next few paragraphs of intro and go to the red text.

 

As mentioned by others, this problem is very insignificant in the grand scheme of things, but anyone who likes to fly an NG like I do will know that if anything can be made more realistic, it should be!

 

As a home cockpit builder, everything counts, and this is especially true when it comes to the flight model and engine dynamics. After tweaking the FS9 PMDG 737NG for the last few months, merging it with the FSX POSky visual model and with many adjustments to the .cfg and .air files, I'm finally in a position where I'm completely satisfied with it in FSX. You may ask: why the FS9 version? Although I do own the NGX, I am not able to remove the inbuilt system logic which conflicts with the interactions of the Project Magenta cockpit software I use. As a result, I use it purely as a reference in modifying other things...

 

Back to topic: It was during the months of gradual tweaking that I discovered an interesting line in the aircraft.cfg file. The ESP SDK simply describes it as the "Fuel flow gain constant", and through experimenting I found that it adjusted the rate at which the engines spool, and how much overshoot there was in N1 with thrust changes.

 

I will make clear now that the following is likely to be entirely unsupported by PMDG, and unless you're really familiar with aircraft.cfg editing you should keep a backup of the original file!

 

In addition, there may well be a few side-effects with the setting which I've not found (to be fair, it's likely - I'm no expert!). What the line will do, though, is give you that 2/3 % overshoot on the initial 40/45 % power setting. You could consider it to be an 'N1 stability scalar' if you like, where the higher the value, the less stable the thrust accelerations.

 

For me, it works well in offering the small overshoot and also seems to increase the effect of the 35-45 % N1 boost shown in the original video. The only downside, as I say, is that this will make N1 (power) changes occur slightly faster, so the 45 % to TOGA (final take-off) spool will be not massively, but will be noticably faster than before. In the same way, large N1 decelerations (e.g in an RTO) will cause an overshoot. (98 % N1 will decrease to very high teens before idle is re-established in the low 20s. Maybe this is realistic? I have no idea!

 

Of course, it certainly is not difficult to change back the setting if you don't like the result, and (thankfully) it definitely does not involve any complex .air file editing. By all means give it a try, but be prepared to restore your backup .cfg if you don't like the new effect!

 

The line I changed is found in the [TurbineEngineData] section of the aircraft.cfg. It will need adjusting for every NGX variant you have - but has only been tested on the -800!

 

By default, the first line reads:

 

fuel_flow_gain=0.002

 

This can be increased slightly, I used 0.004 and am very happy with that value (although 0.003 or 0.0035 will give the same result to a lesser extent).

 

Give it a try and post back your findings. As stated, this is not tested extensively and may have other side-effects. I will not be responsible for any damage to your software installation, and I'm only guessing that we're working inside the EULA (maybe I should check that!).

 

 

Regardless, have fun guys!

 

 

 

 

 

EDIT:

One more thing while I think about it- for anyone not used to editing the aircraft.cfg file, you shouldn't do this while FSX is running!

I have noticed this behavior, that although the NGX "bites" at around 40%, as PMDG have stated before, the real NG also seems to have an extra boost at around 35% as mentioned by the topic starter. To get over this, I sometimes apply thrust as Arjen does in his video during taxi and initial spool-up for takeoff. 

I've been following the thread intently over the last few days, and after some initial testing today I may have a solution.

 

Thank you for getting involved in this topic and thank you for this useful information. I have tried your settings, and here's what I like and what i don't like:

 

I like:

1. At higher RPMs, engines are more responsive during small thrust changes.

2. The engines stabilize quicker

3. The slight overshoot during initial spool-up

 

I don't like:

1. The overshoot is very slow and takes a long time to "hop back" to the point where the thrust levers were set at. In this way, we are left with the same problem: an endless wait for stabilization

2. The engines spool-up way to quick at higher RPMs. For example, 40% to TO thrust is now way too fast.

3. Engines decelerate too quickly at lower RPMs. The real engines respond very very slowly between 20 - 30% N1. Only after 30-35% they start to bite.

 

The only thing that this variable appears to be doing, is increasing engine acceleration. But the problem is, that the engine spool-up to 40% in the NGX is pretty much linear, while in real life the spool-up is rather exponentional as you can see in my graph. So the only thing that we are changing here, is making this already linear line, steeper. 

 

So to me it seems, that values of 0.002 - 0.0025 are still the best compromis.

 

I am not sure whether there are other variables that influence engine spool-up. I.e. how did PMDG model the point where the engines start to bite? I think in the .air files, so maybe there is something there that we can change. I don't know how to do that however. Whether there's more to tweak about this, not sure. PMDG probably knows more than us.

 

We don't need a quicker engine spool-up, all we need is the spool-up to be different. We need the engines to spool-up slower in the beginning, while acceleration then increases exponentially, resulting in a boost, overshoot, and quicker stabilization. The total spool-up time however, should remain 8 seconds. 

 

But if this is all we can do, then I understand that this is an FSX limitation. I can life with it just fine, but for me it would add something extra to my sensation of realism. Every detail, no matter how small, adds something for me. That's the exact reason I chose for PMDG.

@ Arjen

 

Thanks for your afford trying to make this awesome product even better! 

I can confirm your observation!

 

It´s sad, that PMDG doesn´t have a slightly different way of communicating to their customers, because they would have a great benefit from that! And the biggest problem is, that this spirit of yelling at everybody who might have an idea how to improve this product takes over to a majority of the forum users - pointing at those bad people who want to criticize... Even for me as 737NG real world driver it´s hard to get through.. always starting with the same arguments like

1. No you are wrong

2. It´s maybe a rare company option

3. this is not possible because of the FSX environment...

and so on and so on...

 

PMDG is the best, everybody knows that. They created a great software with a tiny team. Awesome! And I still hope that maybe one beautiful day, they will realize it and start to be kind, forgiving and greateful to their custumers, because they can, because they are the best!

 

So keep on bringing your great input´s! I also will continue to produce my videos, advertising their products - even if they don´t answer my mails or if they answer they tell me that I´m wrong... Because at the end of the day sometimes they adjust things - of course not as a result of your input!! They never say thanks, we didn´t realize that, thanks for your help! - But they do things, and at the end your SIM at home is better then before.. that´s great!

 

 

And now start yelling at me guys haha  

 

Cheers - Berni

 

youtube / skysurfer007

As regards fuel flow gain. If you create a similar table 1505 curve to the one I displayed earlier, then fuel flow gain needs to be set to 1.

Table 1505 represents in effect time to n2 and the convex curve done by MS is not correct it should be concave.

You need to be somewhat familiar to what you're doing. In table 1505 the horizontal lines represnt time intervals and the curve fuel flow. It does not however, affect fuel consumption!!

Thanks for your afford trying to make this awesome product even better! 

I can confirm your observation!

 

 

Hi Berni and thanks for your input (love your vids btw).

 

From now on nobody can say anymore that I'm wrong. I have video evidence, data evidence, and the input from a real-world pilot. 

 

Anyone attempting to prove me wrong is wrong himself. 

 

To anyone supporting this thread, please try to keep it alive as best as you can, you never know what it might turn into. 

Generally, (again, experience) N₁ doesn't undershoot more than a percentage of a percent in RL because as the fan slows, gases across the low pressure turbine (LPT) disk tend to keep N₁ deceleration stable.  Acceleration is an unstable event because of inertial force in the fan disk.  The fan will overshoot always on hard acceleration because airflow is driving it to a certain RPM - this airflow combined with acceleration of the mass of the disk causes the overshoot.  You also reach a stage in the engine airflow/RPM in flight where the core is doing very little work to keep that fan running at speed.  Airflow due to ram air forces in the inlet keep the fan going, the core only provides a low energy impetus to keep the fan at thrust settings while in flight.  That's what makes the turbofan engine so fuel efficient.  Based on altitude and airspeed, that surge on N₁ will be different due to density, temperature, and pressure on the fan disk due to ram air pressure when in flight.  This is the flight envelope where the engine is the most responsive to inputs as well.  The largest overspeed and surge in RPM and "bite" will occur on takeoff. 

 

Not to take away anything from the thread (it's been a good one), but to simulate this effect would take a lot more computational power than one could imagine. 

 

I did some experimentaion with a stopwatch last night and performed different takeoffs from the same airfield in cold weather, hot weather, and in rain or storm front activity.  Fuel and pax/cargo weights remained identical.  Acceleration to V₁ appeared to vary less than 1.5 secs.  In the rain or in cold weather that engine should put out more thrust than on a hot dry day.  Cold humid weather should be the fastest, cold and rainy should be the second fastest (rain adds drag to all facets of the aircraft), and hot (90°F) should take the longest.  The hot day seemed to be the fastest by an average of .92 secs.  All takeoffs were initiated by performing a very unrealistic toggle of the TOGA switch from a standstill just to be consistent.

I believe only modeling an engine out of FSX we would be able to see this kind of behavior, that changes with atmospheric variations. There's another developer that says they're going to bring this to the table. I would love to see this in PMDG's future addons. A2A models an engine outside of FSX, but I don't know if the output thrust they produce also changes with temperature and humidity, or it's more of a gauges only variation.

This is something my experienced "jet mech" ear noticed when I first bought the NGX, and I've seen it in other products from other makers. First, let me insert the default "I love my NGX" comment, because I do.  And to the OP, this is the MOST interesting thread that I've seen on Avsim in my short history here.  I think you have done a great job with this.  Kudos.

 

I've got many years hands-on, as do others who ride these forums, with RL jet engines.  My experience is with the PW F100 and GE F110-series of engine that powers the F-15, F-16, and further developments of these engines are in the F-22 and F-35.  These engines are NOT in civilian aircraft.  I could be very wrong in what I'm going to present for thought, but I don't think so; I think it's related to what you see.  N₂ is a function of T_t2.5 or a similar temperature input and power level angle in the engines that I've worked on.  This generally means that the hydromechanical MEC or UFC (mechanical engine or unified fuel control, depending on which mfgr) is running the N₂ RPM. The RCVV and CIVV (rear compressor and compressor inlet variable vanes) are being scheduled by the MEC/UFC based on PLA, N₂, and T_t2.5 or similar functions.  This is all controlling core speed (N₂ RPM) via a hydromechanical controller (MEC/UFC) and is using fuel pressures and fuel as hydraulic fluid to move vanes in the engine to control core speed.  Fuel flow through the combustor also controls this speed.  So in summary, core RPM is controlled by airflow and fuel flow through the core.

 

Hang on, I'm going somewhere with this...

 

So, you have the core (N₂) rpm and the core is turning at X% RPM.  Now, this is completely independent of fan (N₁) speed.

 

The fans on my engines had inlet guide vanes and convergent/divergent nozzle flaps to prevent fan overspeed and control thrust.  The IGV's might exist on the commercial engines, but honestly speaking, I'm not sure.  However, N₁ speed is a direct function of N₂ speed.  When I would start up a Viper, I could hear (and feel in my butt) the core RPM come up before the fan RPM.  All turbofans I've ever worked on run in what's called a "closed loop".  The EEC or DEC would monitor the fan speed, nozzle position, IGV position, etc., and would watchdog the core operation, but the core is, again, independent.  The EEC or DEC keeps the engine running at peak parameters.  If the EEC or DEC is lost, the MEC/UFC acts as a backup and closes everything up to ensure that you can remain in the air but your max thrust and RPM is fixed at a safe setpoint.

 

Yeah, yeah, sorry, I'm getting to it.

 

So, the core is running independent of the fan, but what the core does controls the fan; i.e, airflow generated in the core runs the fan.  Now, we are on the runway and the engine is stabilized, let's call it 40%.  The stick actuator in the seat pushes the throttles forward.  The core reacts immediately, as in RIGHT NOW, because it is smaller and can spool up faster.  The fan then accelerates to catch up, and actually overshoots the target by a little.  The EEC sees this and slows the core to stabilize the fan RPM.  The fan is not directly driven by the core, it is driven by airflow, and N₁ is a direct function of N₂.  I am pretty confident that this is what you are seeing in the huge high-bypass fans on these engines in RL. 

 

No foreign objects were ingested during the formulation of this post.

I was a Crewchief on the Block A F-16's when they replaced the F-4's. I must admit I did not have my run license but when that fuel was cracked and she lit you could feel it in your chest. Since I became very proficient on the Coleman I spent a lot of time at the Supressor and Trim Pad. Nothing like standing 6' away from an F-4 in full AB.

 

Thanks,

Ron

 

I did some experimentaion with a stopwatch last night and performed different takeoffs from the same airfield in cold weather, hot weather, and in rain or storm front activity.  Fuel and pax/cargo weights remained identical.  Acceleration to V₁ appeared to vary less than 1.5 secs.  In the rain or in cold weather that engine should put out more thrust than on a hot dry day.  Cold humid weather should be the fastest, cold and rainy should be the second fastest (rain adds drag to all facets of the aircraft), and hot (90°F) should take the longest.  The hot day seemed to be the fastest by an average of .92 secs.  All takeoffs were initiated by performing a very unrealistic toggle of the TOGA switch from a standstill just to be consistent.

Bear in mind that engine limitation schedule data is usually based on sea level pressure and asa temperature. So any adjustments in the airfiles have to reflect that.

Test your a/c at a sea level airport. Then factor in ambient temperature changes so that you can for example set where a hot start might occur. In flight at altitude and at certain temperatures check that your max n1 is still within limits. If it's critical you can then model an engine surge (usually just a brief pop to short to reflt on the instruments unless your eyes are glued to them) which could prompt an engine shut down. Also if your data is correct do a slam test to see just how quickly the engine spools up to (eg. 96%n2) that should also be in your engine limitations.

Something needs to be put in perspective here. Even Level D sims don't have to match this small overshoot. That's not to say the engine models used don't simulate it anyway, but it isn't a requirement. The qualification test just looks at the time taken to make the first 10% of the change and the time to make the next 80%. So basically the initial response and the overall transient time. The NGX engine model wouldn't meet Level D tolerances but it is close enough for recreational purposes.

 

It's a very interesting discussion, but given the choice I'd rather PMDG spent time improving the flight model than perfecting the finer detail of engine transient performance.

Arjen and some of you other guys, you're going in to deep!

You have to keep in mind:

1) FSX is a game-level simulator in the $70 range. 

2) FSX was made as an entertainment simulator and never in any way meant to be so close to real life it could be used for training purposes. This means there are a lot (A LOT!) of limitations developers have to take into account and work with.

3) Real life airplane / engine behaviour depents on countless variables. Only a small portion of those variables are modelled in FSX. 

4) There is a limit to the amount of development we can expect from PMDG (or any developer) while keeping the retail price as low (relatively) as they do. "You want more, you pay more".

5) As someone stated above, even real-life Level-D simulators often don't model nuances like these, simply because they don't or hardly do matter for the operation of the aircraft.

 

Besides all of this, do you really think minor imperfections like these reduce your experience/immersion to any significance?

Something needs to be put in perspective here. Even Level D sims don't have to match this small overshoot. That's not to say the engine models used don't simulate it anyway, but it isn't a requirement. The qualification test just looks at the time taken to make the first 10% of the change and the time to make the next 80%. So basically the initial response and the overall transient time. The NGX engine model wouldn't meet Level D tolerances but it is close enough for recreational purposes.

 

It's a very interesting discussion, but given the choice I'd rather PMDG spent time improving the flight model than perfecting the finer detail of engine transient performance.

 

Arjen and some of you other guys, you're going in to deep!

You have to keep in mind:

1) FSX is a game-level simulator in the $70 range. 

2) FSX was made as an entertainment simulator and never in any way meant to be so close to real life it could be used for training purposes. This means there are a lot (A LOT!) of limitations developers have to take into account and work with.

3) Real life airplane / engine behaviour depents on countless variables. Only a small portion of those variables are modelled in FSX. 

4) There is a limit to the amount of development we can expect from PMDG (or any developer) while keeping the retail price as low (relatively) as they do. "You want more, you pay more".

5) As someone stated above, even real-life Level-D simulators often don't model nuances like these, simply because they don't or hardly do matter for the operation of the aircraft.

 

Besides all of this, do you really think minor imperfections like these reduce your experience/immersion to any significance?

 

Ms supplies a basic set of airfile tables which were little changed even in FSX that favour in principle propeller driven a/c. So for jet a/c there are many inherent errors

One has to say that in the majority of a/c add-ons these files are untouched when it comes to engine performance. Being able for example to cruise at mach 0.97 or take of with n2 of 116% when the same power should be available at only 96%n2.

For those developers that do take the trouble it takes a lot of time to get something that is close to reality. So there's nothing wrong with tweaking the numbers. The PMDG a/c are not targeted at those who just want to chuck an a/c around the sky in gay abandon (they can use "flight"). Instead they are designed to mirror as close as possibe the real a/c performance.

I was a Crewchief on the Block A F-16's when they replaced the F-4's. I must admit I did not have my run license but when that fuel was cracked and she lit you could feel it in your chest. Since I became very proficient on the Coleman I spent a lot of time at the Supressor and Trim Pad. Nothing like standing 6' away from an F-4 in full AB.

 

Thanks,

Ron

 

Hi, Ron,

 

Thank you for your service.  I was a crewchief as well, and after the first Gulf War, they pulled most of the backshop guys out to the line and crosstrained them to be CC's, and we received in-depth training all the way up to and including engine trim, test cell ops, and even module R² at the engine shop.  If you think the F-4 was loud (I started out on RF-4C's), you should try a Block 52 F-16C with the F110-GE-129 in it.  Cave your ribcage in, you would think.  Rockin'!

 

Best,

 

Kev

 

Something needs to be put in perspective here. Even Level D sims don't have to match this small overshoot. That's not to say the engine models used don't simulate it anyway, but it isn't a requirement. The qualification test just looks at the time taken to make the first 10% of the change and the time to make the next 80%. So basically the initial response and the overall transient time. The NGX engine model wouldn't meet Level D tolerances but it is close enough for recreational purposes.

 

It's a very interesting discussion, but given the choice I'd rather PMDG spent time improving the flight model than perfecting the finer detail of engine transient performance.

 

And that's why I'm hanging in here, to make it interesting.  PMDG isn't going to change it, nor am I.

 

Arjen and some of you other guys, you're going in to deep!

You have to keep in mind:

1) FSX is a game-level simulator in the $70 range. 

2) FSX was made as an entertainment simulator and never in any way meant to be so close to real life it could be used for training purposes. This means there are a lot (A LOT!) of limitations developers have to take into account and work with.

3) Real life airplane / engine behaviour depents on countless variables. Only a small portion of those variables are modelled in FSX. 

4) There is a limit to the amount of development we can expect from PMDG (or any developer) while keeping the retail price as low (relatively) as they do. "You want more, you pay more".

5) As someone stated above, even real-life Level-D simulators often don't model nuances like these, simply because they don't or hardly do matter for the operation of the aircraft.

 

Besides all of this, do you really think minor imperfections like these reduce your experience/immersion to any significance?

 

This isn't too deep.  This is a good discussion.

 

My NGX will remain untouched, as it does what it should; provide me with technical entertainment.  I enjoy technical entertainment.  My wife refers to my sim as "technical pornography", because I enjoy it too much (not porn, the sim...). :p0503:

 

If you guys will notice, I said several posts ago that there isn't enough computational power to accurately generate this effect in our PC's.  I've got a +5GHz Core i7 with 16Gb of fast memory running dual GPU's and I would have to have this rig just run the engines and that's all it could run and even then it wouldn't be correct because there's just too many holes in the data required for accuracy. 

 

But I do like talking about something I know about; thrust you can trust! 

 

Kev