Jet Engine Performance

jx_ · 14 Jul 2012

WarpD said:
Y is definitely not mach. Wow.

Oh... and snide remarks about how I need to read the whole thread (been here from the start, actually) are totally inappropriate and uncalled for. You do not need to be rude.

Hey Ed, wasn't trying to be rude or snide. Text has no tone of voice. Mean you no disrespect, but your comments sounded as if you didn't.

and if X is CN1 then Y is in fact Mach. You can't look up a row without a row reference. That is why the table is called Thrust by Mach vs Cn1.

If X is column, then Y is row.

.......X.......X.......X.......X <-- if this is CN1, then Y is Mach.
Y...result..result..result
Y...result..result..result
Y...result..result..result
Y

EDIT: After reading Tom's latest response I suspect you are making the mistake he is making. I am not debating what AAM labels things as but, simply, what a table look up is. I don't use AAM, I edit in text tables. In a text table with two inputs to be looked up, one is X and one is Y. X down, Y across. Hope this helps.

jx_ · 14 Jul 2012

Hey Roy,

The only problem is that the thrust/altitude results do not match Engine Sim or real world values.

Yes, and what I had been trying to explain to you is it is because SFC in the real counterpart changes at the same RPM/mach, but different altitude and temp. I understand you have performance manuals, but AFMs, FCOMs, FPPMs, and POHs don't give the complete picture.

What I have is in flight telemetry that clearly shows me everything from CL/CD, wing lift Pounds, D drag pounds, FN net thrust pounds, mFF, N1, to EPR...etc etc. All with Altitude, IAS, EAS, CAS, TAS, mach, temp, and so forth. I have static, climb, cruise, descent, glide, driftdown, and abnormal. I can see and compare thrust pounds in each configuration, which is what really matters, and this is what leads to my conclusions. I have really good data to test, and guess what, the sim is spot on everywhere except for the ram drag bug.

What I have been trying to get you to understand is your problem has nothing to do with RPM. You are simply applying a bandaid that will give incorrect N1/N2 readings, unless of course you fudge the display.

As I have stated from the beginning, if the ram drag table worked as it should, we would easily be able to fix this problem. However, it doesn't, and so other means must be found.

I can guarantee from experience, that your problem is from constant SFC as dictated in the cfg file, just like I can guarantee to all those people out there who wrongly believe that FS ground friction is too high, that it is not...the problem is Cruise SFC on the ground.

You seem like a knowledgeable guy, so lets consider this. Would you agree that at the same RPM, a jet is more efficient at higher altitudes, up to it's optimum, than lower?

If that is the case, and you put in the REAL thrust value into 1506, the net thrust output in pounds would be less at sea level (with fuel flow unchanged) while the pounds at 40,000 would increase (with fuel flow unchanged.)

Hypothetical example:

MSFS

Sea level 100%N1 ---- 20,000FN/15,000FF = 0.75 SFC
40,000 100%N1 ----- 5,000FN/ 3,750FF = 0.75 SFC

Real world

Sea level 100%N1 ---- 20,000FN/15,000FF = 0.75 SFC
40,000 100%N1 ----- 7,500FN/ 3,750FF = 0.50 SFC

This is a 50% increase in Thrust pounds at high altitude from a 33% improvement in fuel efficiency, exact same N1 and fuel flow.

This is a visualization of what would be, now let's look at what is.

You set your sea level thrust, by matching the performance manual indicated fuel flows to N1 % and airspeed (Vmo/Mmo in your case). The problem is, at sea level mach by RPM, if the engine should be less efficient in reality, then you have just set an underpowered high altitude condition.

If you have detailed enough information to see the actual thrust pound output of your real counterpart, calculate the SFC at the altitude/RPM/Mach, then set it accordingly. Test it in flight sim, and tweak it to achieve the real performance. Then adjust the SFC to low altitude and test it and you will see what I mean.

If you don't have detailed enough info, then it's all a guess and your opinion anyway, but please don't blame the sim and misinform people. (not in a rude tone, but in a let's not make the problem worse, people are confused enough as it is tone.)

Now, your next question is going to be, if the ram drag bug makes it impossible for us to manipulate this, and there is no way in FS to adjust SFC on the fly, how does this help?

If no one knows about it, no one will try. I know, therefore I have been working on it, and have accomplished just that, adjustable SFC in flight. But maybe one of you brilliant fellows can come up with something I missed or something better. Maybe someone who didn't know will read this post and develop the solution, someone like a Doug Dawson who can manipulate almost anything thru FSUIPC. But the way this conversation has been anti-solution, pro-I don't want to believe anything I don't already believe... I doubt it. But who knows.

Finally Roy,

FSX uses corrected N1 (CN1). The correction involves dividing N1 by the square root of total temperature ratio using degrees Kelvin. In this case the thrust decrease will be with pressure ratio, because of the relationship between density, pressure and temperature in degrees Kelvin.

If you still believe CN1 has anything to do with thrust changes due to altitude then I really can't help you. The equation you cite here concerns "correction." N1 % correction has nothing to do with thrust pound output. It gives gauge programmers the option of using the A:Turb Eng Corrected N1 variable or the A:Turb Eng N1 variable which will display two different fan speeds... one with temp corrections, and one raw. You could (for illustration purposes) use CN1 on engine 1 and N1 on engine two and have different fan speed readings with identical thrust output.

All I can say is, every FDE I've worked on, CN1/CN2 change as per the real aircraft at all altitudes, and setting thrust is always a completely separate process. The key to getting it right has been SFC.

Good luck.

jx_ · 14 Jul 2012

Tom,

Here is the thing I realized.... you are naming Y from AAM. That is AAM's method of displaying data, not MSFS. I'm not describing how AAM works, I am talking about MSFS. There lies the X/Y confusion so that is solved.

The table you described is in fact a 2D table. X, Y are the 2 'dimensions' A 3D table is X, Y, Z. Even a case look up is 2D, but it's the closest you will ever get to 1 dimension because a case can only have one row without a second input.

A B C D E F G (Case 5) = E

X >>> 1 2 3 4 5 6 7
Y >>> A B C D E F G (Case 5) = E

Every airfile editor has it's own display method and you are forgetting that. Air Ed shows Mach as X and CN1 as Y, AAM as you pointed out...and so on. But what really matters is this:

Code:

CN1        M0            M0.9
==================================
0	 0.00000        0.00000
20 	 0.02540	0.07409
25 	 0.05080	0.15929
30	 0.07983	0.25563
35	 0.11249	0.34829
40 	 0.20000        0.44457
45 	 0.28100	0.54086
50	 0.36800	0.70600

X = ROWS, CN1
Y = COLUMNS, MACH
Fields = RESULTS, THRUST FACTOR

X down, Y across.

In the example table you posted... which is the raw 2D table from a text airfile... you hit the nail on the head.

If CN1 is 33.2134 and mach is 0.6345, the sim will look up the two X columns and two Y rows (see previous post... I already explained this) and interpolate the table. As I said before MSFS interpolates from the table fields and not from the actual Mach or CN1, but that's a whole other conversation.

If you don't agree or understand that AAM's nomenclature does not define or represent MSFS tables, or how that info is looked up, then there is nothing to discuss here.

WarpD · 14 Jul 2012

jx_ said:
EDIT: After reading Tom's latest response I suspect you are making the mistake he is making. I am not debating what AAM labels things as but, simply, what a table look up is. I don't use AAM, I edit in text tables. In a text table with two inputs to be looked up, one is X and one is Y. X down, Y across. Hope this helps.

No... I'm looking at the raw data format as defined in the .asm file. It is 23 rows and three columns. The very first row has 3 values, two of which are used and one is not. The first column is unused, the second column is the low mach value and the third column is the high mach value.
The other 20 rows represent CN1 values in column one, Gross Thrust (corrected)/static thrust for low mach in column two and Gross Thrust (corrected)/static thrust for high mach in column three.

In no way, shape or form can mach be considered the 'Y' value. It is instead used to do a standard slope forecast between the low mach and high mach columns of data.

Here is the accurate and official definition of TBL1506:

Code:

	;N1 vs Thrust table (max 21 rows, 11 columns)
	;IN: X: Mach
	;IN: Y: N1 (corrected)
	;OUT: Gross Thurst (corrected) / static thrust
        TOKEN_BEGIN     AIR_70_N1_AND_MACH_ON_THRUST

        UINT32 21,3     ;ROWS,COLS
	;        N1
        REAL8    0.0,      0.0,        0.9 ; Mach
        REAL8    0.0,  0.00000,    0.00000
        REAL8   20.0,  0.02540,    0.07409
        REAL8   25.0,  0.05080,    0.15929
        REAL8   30.0,  0.07983,    0.25563
        REAL8   35.0,  0.11249,    0.34829
        REAL8   40.0,  0.20000,    0.44457
        REAL8   45.0,  0.28100,    0.54086
        REAL8   50.0,  0.36800,    0.70600
        REAL8   55.0,  0.44500,    0.84400
        REAL8   60.0,  0.52100,    0.99700
        REAL8   65.0,  0.62900,    1.15500
        REAL8   70.0,  0.72600,    1.32400
        REAL8   75.0,  0.81800,    1.57500
        REAL8   80.0,  0.90000,    1.77400
        REAL8   85.0,  0.99200,    1.95300
        REAL8   90.0,  1.04300,    2.05500
        REAL8   95.0,  1.06900,    2.15700
        REAL8  100.0,  1.12500,    2.24400
        REAL8  105.0,  1.14500,    2.27500
        REAL8  110.0,  1.17000,    2.31600

        TOKEN_END

The correct method of using this data is to determine the low and high CN1 ranges. Then calculate the forecast value from the slopes of both the low mach and high mach thrust references. Then calculate the forecast value from the two resulting reference values based on actual mach.

Roy Holmes · 14 Jul 2012

Jx_

I can guarantee from experience, that your problem is from constant SFC as dictated in the cfg file

Are you saying that TSFC in the config file affects thrust?

Roy

taguilo · 14 Jul 2012

jx_ said:
Tom,

Here is the thing I realized.... you are naming Y from AAM. That is AAM's method of displaying data, not MSFS. I'm not describing how AAM works, I am talking about MSFS. There lies the X/Y confusion so that is solved.

This has nothing to do with AAM's method of displaying data. What we are talking about is the Y value, not the Y axis of a table. In a simple equation, the source/known value is usually represented by X, and the resulting/unknown value by Y. Of course that different editors may show axis in a different way, but the point here is that we need to obtain a Thrust Factor number (Y) from a given source value, CN1 (X). And in this case, we can consider Mach number as another source/known X value; if you check AAM (do you have it?) you'll see that both graphical methods are represented with CN1 and Mach as X sources.
Notice also that in Ed's recent post table 1506 is depicted with IN X=Mach and IN Y=N1(corrected); that clearly talks about X rows and Y cols of the table, and not related to a graphical display. I think AAM does a good approach when using the Y axis to match the Y value that is to be extracted by the calcs.

jx_ said:
If CN1 is 33.2134 and mach is 0.6345, the sim will look up the two X columns and two Y rows (see previous post... I already explained this) and interpolate the table.

Yes, that's correct (is pretty obvious, to be fair). And if you take the AAM table and make the code that does the calcs, you will obtain the same value that FS displays (can be checked using AFSD).

jx_ said:
As I said before MSFS interpolates from the table fields and not from the actual Mach or CN1, but that's a whole other conversation.

Actually it uses linear interpolation between data source rows and columns. In this particular case, it uses current CN1 value (the same that you can read on a gauge) and current Mach (ditto), and CN1/Mach lower- than/higher-than table values as boundaries.

jx_ said:
If you don't agree or understand that AAM's nomenclature does not define or represent MSFS tables, or how that info is looked up, then there is nothing to discuss here.

I wouldn't dare to say that AAM is a bad or inaccurate source. Most of its data was first researched and identified by Ron Freimuth who was one of biggest FS contributor and a great person as well. I had the pleasure to receive much help from him in my initial developments, and we were kinda working together in some FS dynamics when he unfortunately passed away. Hats off to Ron!

Tom

taguilo · 14 Jul 2012

WarpD said:
The correct method of using this data is to determine the low and high CN1 ranges. Then calculate the forecast value from the slopes of both the low mach and high mach thrust references. Then calculate the forecast value from the two resulting reference values based on actual mach.

I completely agree, of course.

Tom

jx_ · 14 Jul 2012

Ed,

You guys are entirely too intelligent to be this dense. Now I KNOW you're making that mistake.

First of all, .asm files are AAM proprietary. Only AAM uses them. Each editor uses a different format, with different table styles and X,Y identifiers. The airfile itself is not text readable.

Second, what you call the first column is not unused, it's not even part of the table (REAL8). The table is 21x3.

21,3 ;ROWS,COLS

(THREE columns not four)

The first column you call X is just column 1. The first row I call Y is just row 1. So it is X=N1 Y=Mach -OR- X=column1 Y=row1. Also, there can be waaayyyy more than just two mach columns. I have used 20 before. My current project uses 5 mach columns and 25 N1 rows. The sim looks up Mach then finds the appropriate row to look up CN1 (or vice versa...same result), but it needs to look up both to find the result, hence 2D table. If you reverse the order, start from High Mach/High RPM in the top left, the sim is still able to read it correctly.

X and Y come from:

Current user aircraft CN1% = asm:X or aired:Y
Current user aircraft Mach = asm:Y or aired:X

or better yet (A:Turb EngX Corrected N1, percent) and (A:Airspeed Mach,mach)

This is the aired format. (I highlighted Mach header in green.) This table uses 6 Mach columns. X=1 Y=1 is not useable BECAUSE it is a 2 dimensional X by Y table that needs both look ups to work. X=1 Y=1 (in red) will always be unusable.

Code:

Record: 1506 *!Turbine Corrected Thrust Factor vs CN1 and Mach No.
columns: 7  rows: 22
[COLOR="Red"]0.000000[/COLOR]	[COLOR="Lime"]0.000000	0.180000	0.350000	0.450000	0.650000	0.850000[/COLOR]	
0.000000	0.000000	0.000000	0.000000	0.000000	0.000000	0.000000	
0.000000	0.000000	0.000000	0.000000	0.000000	0.000000	0.000000	
0.000000	0.000000	0.000000	0.000000	0.000000	0.000000	0.000000	
4.500000	0.000000	0.000000	0.000000	0.000000	0.000000	0.000000	
5.000000	0.000001	0.000001	0.000001	0.000001	0.000001	0.000001	
22.800000	0.117500	0.120000	0.125000	0.125000	0.150000	0.200000	
25.300000	0.130000	0.130000	0.150000	0.150000	0.200000	0.250000	
30.400000	0.150000	0.150000	0.200000	0.200000	0.220000	0.300000	
38.000000	0.200000	0.200000	0.210000	0.210000	0.250000	0.350000	
44.000000	0.250000	0.250000	0.230000	0.230000	0.300000	0.400000	
47.000000	0.300000	0.300000	0.250000	0.250000	0.350000	0.450000	
59.500000	0.550000	0.550000	0.300000	0.300000	0.450000	0.550000	
68.000000	0.600000	0.600000	0.400000	0.400000	0.550000	0.650000	
76.500000	0.650000	0.650000	0.550000	0.550000	0.650000	0.700000	
80.000000	0.700000	0.800000	0.820000	0.840000	0.880000	0.804000	
85.000000	0.850000	0.850000	0.870000	0.880000	0.950000	1.050000	
87.500000	0.875000	0.875000	0.890000	0.900000	1.000000	1.100000	
90.000000	0.900000	0.910000	0.920000	0.930000	1.030000	1.130000	
95.000000	0.950000	0.950000	0.950000	0.980000	1.050000	1.150000	
100.000000	0.980000	0.980000	0.980000	1.000000	1.100000	1.200000	
110.000000	1.000000	1.000000	1.000000	1.050000	1.130000	1.250000

I'm really starting to believe you guys don't want to hear anything other than what you think is right....so it seems pointless to even discuss it.

jx_ · 14 Jul 2012

Roy Holmes said:
Jx_

Are you saying that TSFC in the config file affects thrust?

Roy

Hello again Roy,

No I am not. I see how you could interpret it that way but what I am saying is the opposite, that in a real aircraft SFC is dynamic and the product of the math equation. In MSFS it is a set constant, the egg before chicken the if you will.

If the ram drag table worked correctly, MSFS turbine engine efficiency would erode and thus SFC would increase dynamically based on the environment. Your low altitude thrust would be lower at 100% and your high altitude higher at the same RPM, 100%, not as a result of SFC, but because SFC is the product of the equation. While the cfg file TSFC does not affect thrust, any changes in SFC within the sim reflect changes in the thrust to fuel flow ratio.

So it's not that it affects thrust, but that it affects the relationship between thrust, fuel flow, and N1 that the FDE designer may logically assume is correct, failing to realize you can never get the correct balance if the SFC is off. And that is the issue, not the sim, but us, the FDE designers failing to realize we have been chasing the wrong tail all along. No real world turbine maintains a constant SFC, and in fact, the vast majority are two to three times more efficient static than at cruise, and half better at cruise than at low altitude, same RPM.

Roy Holmes · 14 Jul 2012

Then what do you mean by this

All I can say is, every FDE I've worked on, CN1/CN2 change as per the real aircraft at all altitudes, and setting thrust is always a completely separate process. The key to getting it right has been SFC

That again sounds like you are saying that the key to setting thrust in SFC

Roy

jx_ · 14 Jul 2012

Roy Holmes said:
Then what do you mean by this

That again sounds like you are saying that the key to setting thrust in SFC

Roy

The way I would say it is the key to an FDE designer knowing how to set correct thrust in all flight regimes is dynamically changing SFC.

The process of developing an airfile is one of feedback and correction. We test-fly, tweak, test-fly, tweak. If the SFC is wrong, your decision making is sabotaged. You are tweaking the sim engine to match the real engines fuel flow/speed/N1, when in fact your engine is producing a different amount of thrust pounds than the real thing. This is what leads to your 25% less thrust theory.

So yes the key is SFC, but not SFC in the cfg file. Remember SFC is the byproduct of mFF/FN. You don't set SFC, SFC is derived from a math computation. So if inflight in the sim, SFC were to change, that means net thrust has changed!

In order for SFC to change, thrust must change at a given fuel flow. Fuel flow is a constant. One pound of fuel will always weigh one pound and always produce the same amount of heat energy when burned. The only thing that changes is the ability of the engine to convert that pound of fuel to a pound of thrust. I realize you know this but am citing it for clarity.

What all this boils down to is the simulated engine is in fact producing more thrust at the same fuel flow when SFC is comparatively less. As an FDE designer yourself, I am sure you have set your aircraft to burn the correct amount of fuel flow at the correct fan speed as per the performance manual. But if your SFC is not matching the SFC of the engine that the manual reflects, your thrust is off. This is a mathematical fact and the source of your problem. In order to see the true relationship between the thrust produced by the sim and in your case, altitude, you need to replicate the true SFC of the engine under those conditions.

In my experience, with correct SFC, the sim produces thrust very similar to the real world data in all regimes, altitudes, and speeds without trickery or gauge play.

Roy Holmes · 15 Jul 2012

In FSX with the TSFC in the config file as say 1.0, set the throttle to give some steady N1 and note the fuel consumption rate and thrust. Then edit the TSFC to be 0.5, reload the aircraft, let the engine settle back to the same steady N1.

The fuel consumption rate will be exactly 50% of what it was before and the thrust will be exactly the same as before.

The TSFC config file entry is an improvement on the older, but still present fuel_flow_scalar entry, but it effectively is simply a scalar on whatever the default TSFC is is in FSX. I'm inclined to think it is about 0.5. The sole purpose of the TSFC entry is to give you the ability to have fuel flow rates displayed that are more realistic for the engines concerned.

I had hoped that the post I made about my method of recovering enough of the thrust loss with altitude in FS would be simple enough for you to understand. I appear to have failed.

The salient point is that the method, by increasing CN2 and therefore CN1 as altitude is increased, means that 1506 now uses higher values of CN1 which have higher Turbine Corrected Thrust Factors (TCTF). These factors apply a small increase in thrust compared to what would happen at constant CN1 and so offset the stock reduction rate with altitude increase. If Mach is kept the same and CN1 input to 1506 is increased then the TCTF numbers will rise, giving the desired effect. The program will interpolate between the entries of CN1 in the table to come up with a value of TCTF and as it increases so the effect of the TCTF contribution to the result of the equation will offset the reduction in thrust played by the altitude/pressure ratio term in the equation.

Of course the increase in CN1 will be maybe unrealistic, but the corrected values are not displayed to the pilots, they only see "gage" N1/N2 not CN1/CN2.

Fact is it works and I hope you now understand what I have done. If not, as you have occasionally said "then there is nothing to discuss here".

Roy

jx_ · 15 Jul 2012

Okay Roy. You're not getting it.

You are too focused on fuel pounds instead of the source of your problem which is thrust pounds. MSFS is backward when it comes to SFC. As i said before fuel flow should be constant and thrust should scale.

Let's make a fictional Boeing 797 that gets 10,000lbs SSL max.

At SSLmax it achieves 0.30 SFC efficiency. This means 3,000 lbs fuel flow paid for 10,000 lbs of thrust.
Inflight at takeoff thrust at sea level, max operating mach, it gets 0.70. This means 7,000 lbs fuel flow paid for 10,000 lbs of thrust.
Inflight at takeoff thrust at 40,000 feet, max operating mach, it gets 0.60. This means 6,000 lbs fuel flow paid for 10,000 lbs of thrust.

How do you replicate that in flight sim? And if you can't what would be the obvious outcome? Your power curve would be screwed!

If you are trying to replicate this and you see in a performance chart that the 797 burns 6,000 lbs of fuel at 40,000 feet at some speed... but you programmed your takeoff thrust to be 7,000lbs fuel flow, you would have had to roll back the numbers in 1506, or increased the TSFC value in the cfg to keep from being a rocket. Why?

7,000FF at 0.30SFC = 21,000lbs thrust
7,000FF at 0.50SFC = 14,000lbs of thrust
7,000FF at 0.60SFC = 11,667lbs of thrust

As you can plainly see all of those are over powered at the same fuel flow and would be at identical fan speeds. So the ONLY way low altitude performance would be right is if you either a) set the correct higher SFC of 0.70, or b) scaled back all your 1506 thrust values at a lower, incorrect SFC. Both would cause your high altitude performance to be underpowered.

So now since you rolled thrust or fuel flows back, not knowing the SFC at takeoff of 0.70 is the real reason you were overpowered, when you check your 40,000 performance you assume the sim calculates power fall off incorrectly........

In FSX with the TSFC in the config file as say 1.0, set the throttle to give some steady N1 and note the fuel consumption rate and thrust. Then edit the TSFC to be 0.5, reload the aircraft, let the engine settle back to the same steady N1.

*pulls hair out* If you reduce TSFC in the config, but INCREASE 1506 proportionally to regain the proper fuel flow, you INCREASE thrust at the SAME fuel flow.

Likewise, if your plane is underpowered at 40,000 and you reduce TSFC, but INCREASE 1506 proportionally to regain the proper fuel flow, you INCREASE thrust at 40,000 feet, at the SAME fuel flow...meaning the correct one shown in the performance manual. This will now make you overpowered at sea level. Why? BECAUSE SFC IS CONSTANT. The real plane wouldn't gain that thrust in both places because it is less efficient in one and more efficient in the other.

If you have the proper SFC at both altitudes, you've effectively increased thrust at 40,000 feet, and decreased thrust at 1,000 feet, without touching anything.

Fact is it works and I hope you now understand what I have done.

Never said it didn't or did work and never had a problem understanding what you were trying to do. I am simply saying that your statement that the sim miscalculates thrust with altitude is flat out wrong and misinforming the readers of this forum with an assumed theory. At the same time, I was trying to help you see that there is a functional solution. But in order to see, your eyes must be open. I'm not typing all this and divulging my FDE secrets to win a pissing contest...

Which brings me to the question.... How do you know it works if you don't have complete data? Isn't it mostly guesswork, and if so, why are you so convinced of your theory? Try something different. Learn how the sim really thinks.

WarpD · 15 Jul 2012

It's not an AAM table. The .asm files existed long before AAM. They are the original data formats used by Microsoft.

They are assembler code that gets compiled into a data file with the .air extension. I really don't know where you got the impression they were defined by AAM. Seriously.

Roy Holmes · 15 Jul 2012

jx_
Your comments about the relationship between thrust and TSFC are true so far as different real world engines are concerned.

But, FS comes with one generic type of jet engine, with its own built-iin relationship between thrust and fuel flow.

I just collected some data on a jet where I had commented out the config file TSFC line and had the Fuel_flow_scalar set to 1.0. I collected fuel flow pounds per hour and thrust over the range of N1 from 35% to 97%, on the ground with the brakes on. Being static, the readout of net thrust would be the same as gross thrust since there would be no intake momentum/ram drag.

At each throttle setting I waited until the data readouts on my flight test panel were rock steady, then noted fuel flow and thrust. In all cases the fuel flow was exactly half of the thrust. For example, at 55.9% N1 the fuel flow was 1144 and the thrust was 2288, at 90.5% N1 fuel flow was 4077 and thrust was 8144.

Therefore, the jet engine simulation model that comes with FSX has a built-in TSFC of 0.5, which I mentioned in a previous post and now have data to prove it. By default, the fuel flow that is output as the (A:TURB ENG FUEL FLOW PPH:x, pounds per hour) variable is half of the thrust output as the (A:TURB ENG JET THRUST:x,pounds) variable.

You can not change fuel flow rate in the .air file, except during the starting cycle and I am only talking about normal operating ranges of N1 like 35 and upwards.

You can make the fuel_flow_scalar config file entry something different than 1.0 and it will then scale the fuel flow variable output accordingly. If you made it 2.0 you would be simulating a TSFC of 1.0. Or you can leave the fuel_flow_scalar at 1.0 and make the TSFC equal to 1.0. Both actions will give the same fuel flow rate per hour divided by thrust. If you made the TSFC equal to 0.25 you would halve the default output value for fuel flow.

A fuel_flow_scalar other than 1.0 overrides the TSFC config file entry.

In the real world jet engines have different fuel efficiencies and if you had data on TSFC for any point in the flight envelope you could calculate thrust. However, the data for TSFC would come from knowledge of the thrust and fuel flow rate, so your calculation would just be reverse engineering.

FSX is not the real world. The basic engine modeled has TSFC = 0.5 by default. Changing the config file value for TSFC has no effect on thrust, it just alters fuel flow rate calculated by FSX, so you can fly for different amounts of time before running out of fuel.

TSFC is not an input in FSX or the real world. It is an output calculated from thrust and fuel flow rate. You cannot tell an engine to improve TSFC, it is what it is and usually deteriorates over time as the engine wears out.

The TURB ENG JET THRUST and TURB ENG FUEL FLOW PPH variables are not settable by Simconnect according to the SDK. Since these are the input values you would use to calculate TSFC, you can not adjust TSFC in FSX according to flight conditions, using simconnect.

To sum up, in FSX TSFC has no effect on thrust and you can only have whatever value you put in the config file, it can not be adjusted in flight by simconnect.

Roy

taguilo · 15 Jul 2012

Roy,

I second every word of what you've stated because I've made the same tests and obtained the same results.
In FSX, TSFC is a static variable and its only meaning is to adjust the fuel consumption by increasing/reducing fuel flow rate, which indeed uses a 0.5 factor by default. It cannot be changed in flight, and it is not available to be modified in any table/field of the .air file that I know. It has no effect on thrust calculation, nor in any other sim behavior appart from the described.

Tom

Roy Holmes · 15 Jul 2012

Tom,
Thank you.

Ed,
In post #57 you said

have you ever considered that the FS code has 'protection' built into it to prevent a problem when someone creates an .air file that has 100% purely bogus data?

Got me thinking.
In the Aircraft_Sim_Tech_Zyskowski paper, under "Backwards Compatibility" the author says that they build in the capability for aircraft from older versions of FS that did not have the turbine tables to be able to have similar performance in FSX as they did in the older version of FS, like before FS2002.

Perhaps this would explain why "bogus" air file data could still result in a flyable aircraft. For "protection" read "Backward compatibility"?

Would this be why the FSX main directory includes FS9.exe, FS2000.exe, and FS2002.exe as well as fsx.exe.?

Just curious

Roy

jx_ · 15 Jul 2012

Roy,

Finally a post we can agree on 100%. Now, for the fun part. I've already accomplished this, and as such, SFC affects thrust directly. SFC changes are dependent on the environment and engine conditions. Lower efficiency equates to losses in thrust pounds, which requires a higher setting in table 1506. High altitude has correct power with better efficiency, while low altitude has correct power with worse efficiency...and so on.

Figure out how to reduce your net thrust without changing your fuel flow and you'll see what I mean.

I feel like Morpheus in the Matrix. Open your mind and think creatively Roy, it's not so impossible like you think it is.

Ed,

Whatever the name of the program is, it is still a GUI interpreter file format, and there are ten different formats. What it shows in a text file has nothing to do with the variables that MSFS looks up real time.

Tom,

Ignored...........

WarpD · 15 Jul 2012

jx_ said:
Ed,

Whatever the name of the program is, it is still a GUI interpreter file format, and there are ten different formats. What it shows in a text file has nothing to do with the variables that MSFS looks up real time.

Um.... no. It's a raw text file that's compiled using a custom command-line compiler written by Microsoft. AAM and AirEd are GUI's that have their own interpretations of how to display the compiled data blocks... but the underlying formats are defined by Microsoft.

jx_ · 15 Jul 2012

Roy,

Forgot to mention, if you zero out table 1507, thrust output increases with airspeed due to Ram effect compression as it should, although this would have more noticeable effect at altitudes where high indicated airspeeds are possible and not as noticeable when subsonic at 40,000 feet.